做用户回放分析的人都知道这活儿表面上是在看录屏实际上是在做“考古”——从一堆鼠标轨迹和点击热力里还原用户当时到底在想什么为什么走到了这一步却突然放弃。传统的回放工具能告诉你“用户在哪个页面停留最久”“哪里点击最多”但很难回答一个更关键的问题用户为什么没转化这个“为什么”通常藏在几十秒的犹豫、反复横跳的滚动、以及最终关掉页面的那一下里。我最近在做的这个“UX Agent”就是把大模型接进用户回放分析流程用 AI 自动把回放变成可量化的行为证据链再结合站内漏斗数据找到转化提升点。简单说以前需要 UX 研究员一帧一帧看的录屏现在 Agent 可以批量看完并且按“转化阻碍因子”分类输出结论。这篇文章就把这个项目的完整思路、架构设计、关键代码和踩坑记录全部展开给同样在做 AI 赋能用户研究、站内转化优化的朋友一个可参考的落地样本。1. 项目整体设计与思路拆解1.1 回放数据为什么难分析难点到底在哪先说清楚一个背景。用户回放Session Replay工具如 FullStory、Hotjar、LogRocket它们的核心能力是录制用户在页面上的完整交互过程并且以“时间轴 事件流”的方式回放。听起来很直观但真正分析起来有几个绕不开的坎。第一数据量巨大。一个日活十万的站点一天产生的会话记录可能是几万甚至几十万条。每条会话又有几十到几百个事件包括鼠标移动、点击、滚动、输入、路由变化。人工抽看回放的常规比例是 1% 到 3%也就是说绝大多数会话永远不会被看到。第二行为判断依赖上下文。一个用户在结账页停留了 40 秒最终离开这 40 秒里发生了什么决定了流失原因。用户是卡在某个字段不知道填什么还是对运费产生疑虑或者是加载太慢等不及这些在热力图里完全看不出来只有在回放里结合界面变化、鼠标活动、页面滚动才能推断。第三结论主观性强。两个分析师看同一段回放可能得出“价格敏感导致流失”和“表单太复杂导致流失”两种不同结论。因为回放本身不包含用户意图所有判断都是推测推测就带偏见。所以这个项目的出发点非常明确把“看回放”这个动作本身自动化让 AI 先做一轮筛选和归类人工只负责审核高置信度的关键片段。1.2 为什么选择 Agent 架构而不是直接调大模型很多人会问直接写个 Prompt把回放数据丢给 GPT不就行了吗表面上可以实际上不行。原因有三层。第一层回放数据不是自然语言而是结构化事件流。直接把原始 JSON 事件丢给大模型Token 消耗巨大不说模型在长列表里找关键信号的能力也很差。需要先把事件流做特征提取浓缩成“行为摘要”这本身就是一个独立的处理管线。第二层转化分析不是一次问答能解决的而是多步骤推理。先要看用户在哪个环节流失再定位具体页面再结合行为证据判断原因最后还要跟历史基线对比确认这个问题是否值得优化。每一步都需要不同的数据源和工具调用这不是单轮 LLM 调用能覆盖的而是需要一个能规划和调用工具的 Agent。第三层准确率需要兜底。大模型判断行为原因存在幻觉风险如果直接让 LLM 输出“用户因为价格高而流失”这个结论可能是错的。所以 Agent 架构里必须引入可核验的证据链每个结论都要挂接具体的回放片段或事件序列方便人工复核。所以最终确定的架构是数据管线负责特征提取规则引擎负责初步分类LLM 负责深度语义推断最后所有结论附带证据链接。这四层各司其职而不是把鸡蛋都放在 Prompt 一个篮子里。1.3 目标场景与收益预期先定清楚边界做这类项目最怕范围失控。我最开始也想做“全自动分析所有页面所有用户”后来发现不现实于是把边界收敛到三个核心场景。第一个场景是关键漏斗步骤流失分析。比如从商品详情页到购物车再到结算页每一步的流失用户回放自动抽出来按照流失原因打标签。第二个场景是高频异常路径发现。比如用户在某个页面反复点击非交互元素或者在同一页面循环滚动多次后离开这类“烦躁行为”自动识别并聚成一组。第三个场景是功能上线后的行为对比。新版本上线后Agent 自动对比新旧版本的回放行为指标输出结构化差异报告。预期收益方面我给自己定的量化目标是将需要人工观看的回放数量降低 80% 以上把单次转化问题定位周期从几天压缩到半天以内。后面实际跑下来的结果也基本达到了这个指标。2. 核心细节解析与实操要点2.1 回放数据采集层先懂数据结构才能动手做这个项目的第一步不是写 AI 代码而是理解回放数据到底长什么样。我用的自建采集方案基于开源工具事件结构大致分四类。第一类是鼠标事件包括 mousemove、mousedown、mouseup、click。其中 mousemove 的量最大如果全量存储成本太高实际采集时做了节流每 200 毫秒最多记录一个点并且忽略距离上一个点小于 5 像素的移动。第二类是页面事件包括 scroll、resize、routechange。滚动事件记录了滚动深度和滚动速度这里有个关键字段——滚动速度大于某个阈值时通常意味着用户是快速扫视而非细读。第三类是交互事件包括 input、focus、blur、submit。输入事件要特别注意脱敏我直接不采集输入内容只记录字段名、输入长度、聚焦时长。第四类是视图快照。每隔一段时间或者关键操作发生时截取 DOM 快照用于后续判断用户当时看到了什么界面。一个典型的事件对象大概是这样的结构{ session_id: s_20241115_abc123, user_id: u_8899, timestamp: 1731628800000, event_type: click, selector: #checkout-button, page_url: /cart, coordinate: { x: 320, y: 540 }, viewport: { width: 1440, height: 900 }, scroll_depth: 0.72 }采集层最重要的一个教训是一定要记录页面 URL 和路由变化否则会话串联不起来。我开始时漏掉了 routechange 事件导致一个多页面会话被拆成几段分析结果完全没法用。2.2 会话特征提取把行为浓缩成 LLM 能理解的语言有了原始事件流下一步是把一小时可能上千条的事件压缩成几百字的“行为摘要”。这一步是整个系统效果好坏的分水岭。我做了一套特征提取规则核心思路是关注行为密度和转折点。具体提取的特征包括会话内页面的访问顺序和每个页面的停留时长点击分布特别关注非链接区域的点击如点击图片、空白处、无效按钮最快的页面离开速度通常小于 5 秒的离开意味着首屏有问题表单交互过程包括字段聚焦时间、输入修改次数、最终是否成功提交返回行为和重复行为比如用户是否反复切换商品详情页和购物车这些特征的提取逻辑是可以不断迭代的。第一版我只提取了页面停留时间和点击数LLM 分析得很空全是一些“用户可能对页面不感兴趣”之类的废话。加入“快速离开”“反复切换”“无效点击”这些行为模式后模型的判断明显开始具体。提取完成后的行为摘要模板大概是这样的## 会话路径 首页(8s) - 商品列表页(23s) - 商品详情页A(45s) - 购物车(12s) - 离开 ## 关键行为 - 在商品详情页A快速滚动至底部未点击购买按钮 - 在购物车页面停留12秒鼠标在“优惠码输入框”附近来回移动 - 最终未提交订单直接关闭页面 ## 异常信号 - 购物车页存在一次无效点击点击“优惠码确认”按钮但无响应2.3 AI Agent 的 Prompt 设计让模型遵循行为分析框架这里要强调的是Agent 的 Prompt 不能是“请你分析这个转化问题”这种开放式指令必须给模型一个极其明确的分析框架和输出结构。我在 Prompt 里定义了四个分析维度路径合理性、交互阻力、信息清晰度、信任感。每个维度下又预置了若干判断规则。路径合理性关注的是用户是否按照预期的核心路径前进在哪些节点偏离偏离后是否回正交互阻力关注的是页面是否存在加载阻塞、按钮无响应、表单校验误导等问题。信息清晰度关注的是用户是否因为信息不足或表达不清晰而犹豫不决。信任感关注的是用户是否在价格、支付、安全相关元素处表现出迟疑。Prompt 的核心结构是这样的你是一名资深的用户行为分析专家。请基于以下会话行为摘要分析该用户未完成转化的原因。 分析要求 1. 从路径合理性、交互阻力、信息清晰度、信任感四个维度逐一评估 2. 每个维度用“证据 判断”的格式输出证据必须是行为摘要中出现的事实 3. 最后给出一个主要流失原因判断置信度分为高/中/低 4. 注意区分“明确证据”和“猜测推断”不要将猜测作为结论输出 5. 如果存在技术性异常如按钮无效、加载失败优先标记为高优先级问题 会话行为摘要 {behavior_summary}这套 Prompt 设计里最重要的点是结构化输出约束。因为后续需要自动聚合多段回放的分析结果如果 LLM 输出格式不统一聚合逻辑会非常痛苦。所以我强制要求 JSON 输出并且在 JSON Schema 层面做了校验。2.4 工具调用与多轮推理Agent 怎么“查资料”做交叉验证这个 Agent 不只分析单一会话它真正的价值在于跨会话聚合和多源数据验证。当单会话分析结束后Agent 会发出工具调用请求去查询这个用户的历史行为数据、同类型用户的转化基线、以及该页面的近期 A/B 测试数据。我用的是 ReAct 模式的 Agent 流程定义了几个关键工具class UXAnalysisTools: def get_user_history(self, user_id: str) - dict: 查询指定用户在近30天内的历史行为摘要 pass def get_funnel_baseline(self, page_url: str, date_range: str) - dict: 查询指定页面的转化漏斗基线数据 pass def get_session_replay_url(self, session_id: str) - str: 生成关键片段的回放链接用于人工复核 pass def get_experiment_context(self, page_url: str) - dict: 查询该页面是否有正在运行的实验 pass整个 Agent 的推理流程是这样跑起来的先接收一个会话的行为摘要做单会话分析如果判断“用户对价格敏感”就调用 get_user_history 查询历史下单记录看这个用户是否从来只浏览不购买如果发现“页面可能存在加载问题”就调用 get_funnel_baseline 对比今天的跳出率是否异于平时每次工具调用后把结果合并进上下文再做下一步推理最终输出一个包含置信度标注的根因判断这个设计的好处是让 LLM 的结论可以被数据校验而不是在纯文本里脑补。实际上跑下来加入工具调用后的准确率比纯 Prompt 高了不止一个量级。3. 实操过程与核心环节实现3.1 项目环境与依赖选型如果你要复现这个项目我建议按这样的技术栈来Python 3.11 作为主语言主要因为类型注解和异步支持都更友好。LLM 部分我兼容了 OpenAI 兼容接口和本地部署的模型用 LangChain 做 Agent 框架但只是用了它的基础编排能力大部分逻辑是自己实现的——这后面会讲为什么。数据存储用的是 ClickHouse专门用来存事件流数据。虽然项目初期数据量不大但回放事件属于典型的追加写入、时间范围查询场景ClickHouse 比 PostgreSQL 在这种查询上快得多。如果只是做原型验证SQLite 也够用但建议预留迁移空间。数据处理管线用 Pandas 做特征工程这没什么特别唯一要注意的是内存管理几百万行事件数据一次性加载很容易爆内存后面我改成了按会话 ID 分块处理。整个项目的目录结构大致是这样ux_agent/ ├── collector/ # 回放数据采集 SDK ├── features/ # 特征提取模块 ├── agent/ # LLM Agent 核心逻辑 ├── tools/ # Agent 可调用的工具 ├── aggregator/ # 跨会话聚合与报告生成 └── webapp/ # 简单的结果展示页面3.2 特征提取的完整实现含关键阈值和规则特征提取模块是整个系统的地基我花的时间最多。下面把这个模块的核心逻辑展开讲。会话切分是一个很容易被忽略但十分关键的环节。我按 30 分钟无操作和跨天两个条件切分会话。也就是说一个用户打开页面看了 5 分钟关了电脑晚上又打开这是两个会话。这个规则是通用的行业标准。会话切分完成后就开始提取行为特征。这里给出几个关键的阈值和判断逻辑# 快速离开页面停留时间小于5秒且无点击行为 if page_duration 5 and click_count 0: flags.append(quick_leave) # 无效点击点击元素不是链接、按钮、输入框等可交互元素 if element_tag not in [A, BUTTON, INPUT, TEXTAREA, SELECT]: flags.append(invalid_click) # 反复修改同一个表单字段聚焦超过3次 if focus_count_per_field[field_name] 3: flags.append(field_rework) # 焦虑滚动在页面底部和顶部之间来回滚动超过5轮 if scroll_direction_changes 10: flags.append(anxious_scroll) # 犹豫行为在关键按钮附近出现长时间悬停后离开 if hover_duration_near_checkout 3 and not clicked_submit: flags.append(hesitation_before_action)这些规则的价值在于给 LLM 提供了明确的行为信号而不是让它自己从海量事件里去总结。我测试过直接把原始事件给 LLM 而不过特征提取效果很差模型会忽略低频但关键的行为反而被高频的鼠标移动带偏。特征提取后的最终输出是一个结构化的会话档案里面包含会话基础信息、页面访问序列、行为事件摘要、异常标志列表。这个档案才会进入 Agent 分析环节。3.3 Agent 核心循环的实现手写 ReAct 框架虽然 LangChain 提供了现成的 Agent 封装但我在实际使用后发现一个问题框架自带的重试和格式化逻辑太多了反而限制了执行效率。于是在第二版的时候我直接手写了 ReAct 循环核心代码不到 150 行但可控性大幅提升。核心实现思路如下class UXAgent: def __init__(self, llm, tools): self.llm llm self.tools {t.name: t for t in tools} self.max_rounds 5 def run(self, session_profile: dict) - dict: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: json.dumps(session_profile, ensure_asciiFalse)} ] for round_idx in range(self.max_rounds): response self.llm.invoke(messages) reply response.content # 解析模型输出判断是否包含工具调用 action self._parse_action(reply) if action is None: return reply # 执行工具调用 tool_result self.tools[action[name]].run(**action[args]) messages.append({role: assistant, content: reply}) messages.append({role: tool, content: json.dumps(tool_result, ensure_asciiFalse)}) return self._force_final_answer(messages)这个循环的关键在于_parse_action函数。我让 LLM 在需要工具调用时输出一个特定的 JSON 结构{tool_call: {name: get_user_history, args: {user_id: u_8899}}}然后代码解析这个 JSON执行对应工具把结果作为 tool 消息回传给 LLM继续下一轮推理。我比较了手写和框架实现的差异手写版本的平均时延降低了 40% 左右因为省去了框架层多次 JSON Schema 校验和冗余的消息处理。当然我并不是说框架不能用而是做生产级 Agent 时要警惕框架的“黑盒开销”。3.4 跨会话聚合从单点分析到整体洞察单个会话分析完成后Agent 还会做一步跨会话聚合。这一步的目的是把几十上百条单会话结论合并成一份站内转化提升建议报告。聚合逻辑分三块。第一块是按流失原因聚类。所有会话的流失原因判断会被汇总比如 30% 的流失被归因于“表单字段不清晰”25% 被归因于“运费信息不明”。这个聚合我用的是简单的规则匹配加 LLM 二次归纳。第二块是按页面维度归组。同一个页面的问题会被集中展示比如商品详情页的问题可能有图片加载失败、价格展示不突出、用户评价不可见。这方便产品经理直接找到对应页面的负责人。第三块是给建议排优先级。优先级计算考虑三个因素问题影响面多少会话涉及、置信度均值、修复成本预估。我把这三个因素加权求和得到一个分数按分数排序输出建议清单。最终的报告结构大致如下## 高优先级问题建议1周内修复 1. 问题购物车页“优惠码确认”按钮无响应导致部分用户放弃结算 影响面12% 的购物车页流失会话 证据片段s_20241115_abc123s_20241115_abc456s_20241115_abc789 置信度高存在技术性证据非推测 建议修复方案检查按钮绑定事件是否正确加载增加点击反馈状态 2. 问题结算页未清晰展示运费政策 影响面8% 的结算页流失会话 证据片段s_20241115_def123s_20241115_def456 置信度中存在犹豫行为但无直接证据表明用户因运费离开 建议修复方案在结算前展示运费估算或增加运费说明折叠面板4. 常见问题与排查技巧实录4.1 LLM 判断空泛输出“用户对产品不感兴趣”这类废话怎么办这是最容易遇到的问题本质原因是输入给 LLM 的信息颗粒度不够。如果行为摘要只是“用户在某页面停留了 30 秒”那 LLM 当然只能输出“用户可能对页面不感兴趣”这种废话。解决方法是倒逼自己把特征提取做得更细致。我给行为摘要里加了一个“关键行为片段”字段专门记录异常行为。比如“用户在两秒内滚动整个商品详情页期间未点击任何图片”“用户在商品评价区域悬停 8 秒并放大查看一张差评图片”。有了这样具体的证据LLM 的输出立刻变得有依据。还有一个技巧是在 Prompt 里显式要求“禁止输出不包含具体行为证据的判断”。我在系统提示里写了一句所有结论必须引用至少一条行为摘要中的事实否则视为无效输出。这一条直接把大量空话过滤掉了。4.2 事件数据量大Agent 处理速度太慢怎么办回放数据分析天然面对海量数据如果每个会话都走一遍 LLM成本和时间都不可接受。我做了三个层面的优化。第一层是规则预筛。正常的、没有异常信号的会话直接跳过不进 LLM。我统计过大约 60% 的会话是正常的这些流量不需要 AI 分析。只有命中异常标志的会话才值得深入分析。第二层是并发处理。同一批会话的分析任务丢进线程池控制并发数为 8 到 10 个。LLM 的 API 调用是 IO 密集型的用异步并发能显著提升吞吐量。实测并发 10 个时处理速度提升了约 7 倍。第三层是采样策略。如果异常会话还是太多就按漏斗步骤分层抽样。比如结账页流失的会话全部保留但首页跳出的会话只抽 10%。因为首页跳出可能有大量非目标用户而结账页流失的用户意图明确价值密度更高。4.3 工具调用结果与 LLM 判断矛盾时怎么处理这个情况也很常见。比如 LLM 分析某段回放后判断“用户因为价格高而放弃购买”但调 get_user_history 后发现该用户近 30 天内有 3 笔高客单价订单说明价格敏感这个判断站不住。我现在的处理策略是让工具结果优先于 LLM 判断。如果历史数据与当前推断矛盾Agent 会重新输出一个更保守的结论并把矛盾点记录下来供人工关注。具体实现是给 LLM 加了一个矛盾检测指令当工具返回的数据与你的分析判断不一致时 1. 不要强行统一分别列出模型判断和数据显示 2. 以数据为准修正结论并标注“与历史数据存在矛盾” 3. 将该会话标记为需要人工复核这个设计不是为了找 AI 的错而是为了保留分析的可追溯性。毕竟我们的目标是辅助人做决策不是取代人。4.4 回放数据质量差部分会话事件缺失怎么办事件缺失会导致分析结果出现偏差我在这个坑上也栽过。某次 Agent 报出“用户进入结算页后直接离开无任何交互”后来排查发现是前端 SDK 在结算页加载时初始化失败导致事件上报丢失。应对措施是在特征提取阶段增加一个数据质量评分字段。如果会话的事件数量明显低于正常分布或者存在页面跳转但无对应的进入事件就标记为低质量会话不进入 LLM 分析。这个过滤操作虽然损失了一些样本但保证了分析结论的可信度。还有一个相关的经验是请求重放机制。前端 SDK 采集到事件后先在本地缓存每 5 秒批量上报一次失败自动重试。这能显著降低因为网络波动导致的数据丢失。4.5 常见问题速查表为了方便排查我把常遇到的问题整理成了表格遇到直接对照处理。症状可能原因处理方案LLM 输出空泛判断行为摘要信息颗粒度不足增加关键行为片段字段细化特征提取规则处理速度极慢全量会话都走 LLM增加规则预筛只分析命中异常标志的会话结论与历史数据矛盾单一行为推断不够全面加入工具调用交叉验证矛盾时标记人工复核疑似漏报关键流失原因特征提取规则未覆盖该行为模式定期用人工标注样本评测特征覆盖率迭代规则任务偶发超时LLM API 响应不稳定增加超时重试超时后降级为规则判断数据缺失导致分析偏差前端采集异常增加数据质量评分低质量会话过滤5. 一些更深层的想法与后续扩展5.1 不要迷信大模型的判断本质是概率推理这个项目做下来一个很深的体会是大模型在用户行为分析这个场景里真正强的不是推理能力而是“模式识别后的语言组织能力”。模型能从一个行为摘要里联想到各种可能原因这种联想覆盖面比人脑广但精度未必更高。所以整个系统的设计哲学是LLM 负责提出假设规则和工具负责验证假设。这个哲学贯穿了全部模块的设计。凡是 LLM 的判断必定要回到行为事实或业务数据上做校验不能校验的只能作为低置信度参考。5.2 建立人工反馈闭环持续优化特征规则这个项目不是做一次就完了而是一个持续迭代的过程。我在系统里加了一个反馈通道人工复核后可以标记“Agent 判断正确”或“Agent 判断错误”这些标记会沉淀下来定期用来评估特征提取规则和 Prompt 的准确性。第一版投产时 Agent 的准确率大概在 65% 左右经过两轮反馈迭代后提升到了 82%。提升主要来自两方面一是发现了很多新的异常行为模式比如“用户在优惠码输入框反复粘贴删除”这是开始没覆盖的二是修正了 Prompt 里的一些误导性表述让分析框架更贴合实际业务流程。5.3 后续可以拓展的三个方向这类 Agent 本身的扩展空间非常大。目前我已经在规划三个方向。第一个方向是实时告警。从离线分析升级到准实时分析当检测到某个页面的异常行为指标飙升时自动触发告警并生成问题摘要让产品和技术第一时间介入处理。第二个方向是结合业务数据的深度归因。现在 Agent 主要分析行为数据后续可以把订单数据、客服聊天记录、用户反馈等业务数据也接入进来做行为 业务的联合归因定位更精准。第三个方向是自动生成优化建议并预估影响面。让 Agent 不仅输出问题清单还能结合历史实验数据输出“如果修复这个问题预期转化率提升空间大约在 X% 到 Y%”这样的量化预估直接辅助决策层排优先级。最后说一个我个人的体会做这类 AI 产品最容易犯的错误是一开始就追求“全自动智能分析”结果做出来的东西既不够准也不够落地。更稳妥的做法是先让 AI 做辅助筛选和初步诊断把人工从重复劳动里解放出来让人的精力集中在高价值判断上。等规则和模型都跑顺了再逐步扩大 AI 的决策权限。这个项目走到现在最让我满意的不是模型多聪明而是整个分析流程的效率和准确性真的提升上来了团队从一周看几十条回放变成一天审几百条 Agent 筛选出的关键片段转化问题的发现速度明显加快了。
