做用户回放分析的人都知道，这活儿表面上是在看录屏，实际上是在做“考古”——从一堆鼠标轨迹和点击热力里，还原用户当时到底在想什么，为什么走到了这一步却突然放弃。传统的回放工具能告诉你“用户在哪个页面停留最久”“哪里点击最多”，但很难回答一个更关键的问题：用户为什么没转化？这个“为什么”，通常藏在几十秒的犹豫、反复横跳的滚动、以及最终关掉页面的那一下里。
我最近在做的这个“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_ascii=False)} ] 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_ascii=False)}) 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_abc123，s_20241115_abc456，s_20241115_abc789 置信度：高（存在技术性证据，非推测） 建议修复方案：检查按钮绑定事件是否正确加载，增加点击反馈状态 2. 问题：结算页未清晰展示运费政策 影响面：8% 的结算页流失会话 证据片段：s_20241115_def123，s_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 筛选出的关键片段，转化问题的发现速度明显加快了。
