快手 AI 全栈一面（发券营销）：Agent 可观测性与线上排查

《面试题目》

1. 请做一下自我介绍。
2. Agent 的可观测性是怎么做的？
3. 可观测性链路搭建完毕之后，如果用户反馈某一次提问给出的答案他不满意，要如何排查？怎么确定是 Prompt 的问题还是其他问题？
4. Redis 的分布式锁怎么做会更可靠？分布式锁只能用 Redis 来实现吗？
5. 在公司有没有写过 MCP？什么情况下会考虑开发 MCP？
6. 如果要给 Agent 提供能力，MCP 是唯一的办法吗？
7. 分享一次线上问题的排查情况。
8. 主站挂了大概是什么原因？有没有影响到你们？你们是怎么定位与恢复的？
9. 中台的数据量大约有多少？

《参考解析》

Agent 的可观测性要按「一次调用一条链路」来搭

普通服务的监控是看 QPS、错误率、P99 延迟，Agent 的链路是多步、跨模型的，只看这些指标定位不到问题，所以要把一次用户提问建成一条 trace：入口请求是根 span，往下挂检索、模型调用、工具调用、后处理这些子 span，每个 span 记输入输出摘要、耗时、token 数与成本、模型与参数版本、错误与重试。指标侧再抽出几类聚合量：端到端成功率、首 token 延迟与总延迟、每步耗时占比、工具失败率、单次成本分布。实现上通常分两套：用 LangFuse 这类工具做 trace 与会话回放（能按用户、会话、版本筛选），用 Prometheus 加 Grafana 做指标与告警（因为要接公司统一的告警与容量体系），手写埋点只补两套都覆盖不到的业务字段。要强调的两点是：trace 里必须带版本号（Prompt 版本、模型版本、检索索引版本），否则线上效果变化无法归因；采样策略要分层，错误和高成本请求全采，正常请求按比例采。

用户反馈答案不满意：按链路分层做二分定位

第一步是复现与固定现场：拿到会话 ID 与 trace，确认当时用的 Prompt 版本、模型、检索索引和知识库快照，先把「版本漂移」这个干扰项排掉。第二步按链路自下而上做二分：先看检索层召回的内容对不对（召回为空、召回了过期文档、召回了权限外的内容都属于这一类），再看 Prompt 组装有没有问题（上下文超长被截断、变量没填进去、格式指令和内容冲突），再看模型层（温度、最大输出长度、是否触发了降级模型），最后看工具与后处理（工具参数错误、结果解析失败、答案被后处理规则改写）。判断依据要有客观代理指标：同样的输入换一版 Prompt 或人工重放一次，看输出是否稳定；把召回的上下文贴出来让人判断「给这些材料能不能答对」。如果给对材料能答对，问题在检索；给对材料还答错，问题在 Prompt 或模型；换模型就好则在模型。这套分层的好处是每个结论都能用一次实验证伪，而不是靠猜。

Redis 分布式锁怎么做才可靠

基础实现是 SET key value NX PX ttl，value 用随机唯一值，释放时用 Lua 脚本比对 value 再删，避免删掉别人的锁；TTL 是必须的，否则进程崩溃就是死锁。再往上一层要解决三件事：锁续期（业务执行超过 TTL 时用看门狗线程定期续，或把 TTL 设成业务 P99 的若干倍并配合超时兜底）、可重入与重试（同一线程重复加锁用计数器或本地标识，抢锁失败要退避重试而不是立刻失败）、以及主从切换带来的安全性问题（异步复制下主节点挂了、锁还没同步到从节点，另一个客户端可能同时持锁，所以严格场景要么用 Redlock 多节点投票，要么用 etcd/ZooKeeper 这类基于共识的实现）。所以「只能用 Redis 吗」的答案是不能：Redis 胜在性能与实现简单，适合锁粒度小、冲突短、容忍极小概率误判的场景（比如防重复提交、任务调度去重）；强一致要求高的场景（分布式事务协调、唯一性资源分配）更适合基于共识的协调服务或数据库唯一约束加乐观锁。回答时最好能说出你实际拦住了哪类并发问题，这比背实现更能体现理解。

什么时候值得写 MCP，以及它是不是唯一选择

MCP 的价值在复用和契约：同一批工具要被多个客户端或团队用、要给工具加统一的鉴权与审计、或者工具方与调用方不是同一拨人时，把工具封装成 MCP server 才划算。反过来，工具只有自己的 Agent 用、生命周期和代码一起走，直接函数调用或 Function Calling 就够了，多一层协议只是增加进程通信和排障成本。所以「是不是唯一办法」的答案是否定的，常见替代有四类：代码内直接函数调用（最轻、最可控）、Function Calling 配 OpenAPI 描述、插件或 SDK 形式的内嵌集成、以及 RAG 式的文档说明加固定命令。选型看四个维度：调用方数量、工具与调用的部署边界、是否需要权限与审计、以及团队愿意承担多少协议复杂度。

线上问题排查：先止损再定位，动作要有时间线

回答这类题不要只讲技术根因，先讲处置顺序：确认影响面（哪些用户、哪些接口、是否还在扩大），做能立刻止损的动作（回滚最近变更、切流量、打开降级开关、扩容），同时把信息同步给相关方。然后才是定位：按时间线对齐「什么时候开始异常」与「什么时候有变更发布」，看监控曲线的拐点、依赖方的健康状态、错误日志与链路追踪里的第一个异常点，用排除法缩小到一个组件。恢复后要补两件事：把根因和影响面写清楚，把能防住下一次的动作落地（告警阈值、超时与重试、熔断降级、混沌演练）。中台说自己没出过线上问题也很正常，但面试官更在意你有没有旁观过完整链路、能不能讲清自己在定位里做过什么，所以平时要刻意收集这类案例，别到面试现场才发现没有素材。