字节跳动 客户端基础技术 二面：Agent 诊断链路与置信度阈值

《面试题目》

1. ttu 是怎么埋点的？
2. 说一下性能看板的各个阶段（要求投屏看配置的看板告警）。
3. 优化成效怎么量化？
4. 防劣化怎么做？
5. Agent 中 planner 的作用是什么？
6. Agent 诊断链路是怎样的？
7. 怎么平衡用户体感和意图澄清的次数阈值？
8. 置信度怎么定？
9. 置信度可以通过哪些指标作为依据进行调整？
10. 哪些指标变动后，会对置信度阈值做怎样的调整？
11. 怎么量化生成 UI 诊断报告的成效？
12. 怎么观测真的提高了用户的诊断效率？
13. 反问：校招侧重点是什么？

《参考解析》

ttu 这类端上指标，埋点先定口径，再谈采集链路。 题面没有展开 ttu 的具体定义，回答时第一步应该确认：它从哪个事件开始计时、到哪个事件结束、统计的是用户真实经历还是实验室数据、分母是什么、是否分设备/版本/地域。埋点链路的通用结构是：在客户端关键生命周期节点打时间戳（启动、首屏、可交互、页面停留、异常），由埋点 SDK 统一封装事件名、公共参数（设备、版本、网络、用户分群）、采样率和上报队列；先落本地缓冲，再按批上报，失败重试并做去重；服务端做清洗、校验（时间戳单调性、缺失率、异常值）后进数仓。要保证可信，得做三件事：埋点与业务事件对得上（同一动作只打一次）、有灰度/版本对照、有数据质量监控（量级突变、字段空值、时延分布）。性能指标通常看 P50/P90/P99 而不是均值，因为长尾才是用户体感。投屏讲看板时，不要只念图，按“指标口径—聚合维度—时间窗—告警阈值—通知渠道—值班人—静默规则”讲一遍，面试官就能判断你是真的配过还是只看过。

性能看板要形成“定义—采集—聚合—展示—告警—归因—闭环”的链路。 定义层确定每个指标的计算公式和维度；采集层区分客户端埋点、服务端日志、合成监控；聚合层按时间窗（分钟/小时/天）、版本、机型、地域、网络做分层，避免辛普森悖论；展示层把趋势、分位线、对比基线放在一起；告警层设静态阈值和动态基线（同比/环比/波动率），配分级、静默、抑制和升级策略，避免告警风暴；归因层能下钻到版本、页面、接口、设备；闭环层要求每条告警有 owner、runbook、复盘和行动项。投屏看配置时，重点解释为什么这个阈值不会误报/漏报，告警后先看什么、谁来处理、多久升级。

优化成效要用“对照 + 分位 + 分层 + 时长”四件事证明。 先固定基线：优化前的版本、同样的用户群、同样的时间窗、同样的指标口径；再看 P50/P90/P99 和长尾，不能只报均值；然后做分层：新老用户、机型、网络、地域、页面，确认收益不是某个子群拉高的；最后看持续时间，避免只取发布后一小时的高峰。有条件做灰度 A/B，或者用合成监控/实验室数据做交叉验证；同时盯护栏指标，比如崩溃率、内存、耗电、包大小、转化率，防止“性能涨了、业务掉了”。防劣化则是把性能预算写进 CI/发布门：包大小、启动耗时、首屏、内存有上限，合并前跑基准，超过阈值阻断；线上做版本级趋势告警、灰度对比、异常自动回滚；每个模块有 owner，每月复盘 top 劣化项。关键是把“优化”从一次运动变成持续的门禁和看板。

Planner 的作用是把目标变成可执行、可检查、可重规划的任务图。 它要先理解目标和约束，把任务拆成有依赖关系的步骤，选择每步用哪个工具/模型，安排顺序和并行，设定预算（步数、token、时间）和终止条件；执行器拿到结果后，planner 根据观察决定继续、换工具、回退还是放弃。好的 planner 不是“让模型自由发挥”，而是把计划约束在可校验的 DSL/状态机里：每步有输入输出 schema、成功条件和失败处理，关键节点要人工确认。Agent 诊断链路可以拆成：采集信号（用户描述、日志、指标、trace、配置）→ 归一化并补齐上下文 → 生成假设（按概率排序）→ 调工具取证（查配置、对比基线、复现）→ 做因果校验（排除相关但无关的因素）→ 输出结论和证据 → 人工确认/反馈。每一环都要记录置信度和证据来源，否则最后只是一个看似合理的猜测。

意图澄清阈值本质是“问一句的成本”与“做错的成本”之间的权衡。 问得太多，用户觉得烦、会话变长、流失率上升；问得太少，执行错、返工、信任下降。做法是按风险分层：低风险、可逆的操作，置信度中等就可以先做并说明假设；高风险、不可逆、涉及资金/权限的操作，置信度不够必须问。再设硬上限，比如同一任务最多澄清 2 次，超过就转人工或给候选让用户选。阈值不能拍脑袋，要用数据校准：看意图分类分数、槽位填充率、历史相似意图的成功率、检索证据强度、工具返回一致性；离线用标注 case 画 precision-recall 曲线，按“误执行成本/多问一句成本”选工作点；线上做小流量 A/B，观察澄清轮次、任务完成率、放弃率、用户满意度、平均时长。指标变动时的调整方向要能说清：槽位填充率下降、澄清概率上升、误执行代价上升，就提高阈值多问；放弃率上升、用户频繁打断，就降低阈值或改问法。最好按意图类别分别设阈值，而不是全站一个数。

置信度不是模型说“我很确定”，而是可校准的概率估计。 来源可以分三层：规则/启发式（关键槽位是否齐、参数是否在合法范围）、模型信号（分类概率、生成概率、反思结果）、外部证据（检索命中分数、工具返回是否一致、历史同类任务成功率）。初始值靠工程经验定，再用标注数据做校准：把预测置信度分桶，看每桶的实际正确率，画可靠性图，算 ECE；如果高置信桶的正确率不够，就调整映射或补特征。阈值则按代价矩阵选：漏诊/误执行的代价越高，阈值越高；同时监控三个指标——高置信错误率、低置信拦截率、澄清后成功率。指标变动后的动作可以举例：首轮槽位填充率下降，说明用户表达更模糊，应提高澄清倾向或增加默认值确认；意图澄清概率异常升高，可能是分类器漂移或新意图出现，要先补数据而不是继续调阈值；误执行投诉上升，则提高高风险意图的阈值并加人工确认。所有调整都要有回滚和灰度。

UI 诊断报告的成效要分“结果、过程、业务”三层量化。 结果层看报告结构是否符合 schema、诊断结论是否让外部系统发生了预期变化、有没有曲解用户意图或证据；过程层看 schema 校验通过率、review 重试修复率、引用覆盖率、语义可读性评分、人工返工率；业务层看诊断耗时、一次解决率、转人工率、用户是否按报告行动。观测“真的提高了诊断效率”，不能只看满意度：埋点记录打开报告、停留时长、展开/复制/跳转、是否按建议操作、是否二次提问；服务端记录诊断任务耗时、工具调用次数、失败重试；最好做 A/B 或前后对照，控制问题类型和用户群。反问环节面试官提到校招更看重 AI 认知、计算机基础和思考判断，这其实对应上面的答法：AI 认知体现在你知道 planner、置信度、评测的边界；计算机基础体现在埋点、性能、数据链路能落到机制；思考判断体现在你会先定义口径、再谈优化，而不是堆工具。