哔哩哔哩二面：服务治理与AI评测体系

《面试题目》

1. 个人介绍
2. 服务注册、服务发现和 RPC 调用链路是怎样的？
3. 控制面如何下发 A 调 B 的流量规则？数据面的 Sidecar 或 SDK 如何按照机房比例完成选路？
4. 同一机房内的多个实例可以采用哪些负载均衡策略？为什么实例权重最常用？
5. 不同机型和不同 CPU、内存规格会如何影响实例的吞吐量与流量分配？
6. Agent 在规范治理中负责什么？为什么暂时只允许它创建和管理流水线，而不直接执行治理节点？
7. Agent 如何批量发起治理流水线、监控执行状态、发现异常并触发紧急回滚？
8. 在什么条件下可以进一步让 Agent 托管完整的治理节点和执行流程？
9. Agent Runtime 使用了什么开源框架？当时对比了哪些技术方案？
10. 如何收集真实用户反馈与 Use Case？
11. 评测体系中的确定性指标和 Review Agent 指标分别包含哪些内容？最终分数如何汇总？
12. Token 消耗等指标的阈值如何确定？为什么更关注禁止工具调用等高风险问题？
13. 介绍一下你参与的其他开源项目，其中最复杂的部分是什么？
14. RAG 系统如何提高文档检索的准确性和速度，并管控完整的检索执行流程？
15. 如果设计一个 AI Code Review Skill 或 Agent，你会关注哪些方面的内容？
16. 反问

《参考解析》

服务注册、服务发现与 RPC 调用链路：完整链路是「注册 → 订阅 → 选址 → 调用 → 治理」。服务提供方启动后把 {服务名, IP:Port, 元数据（机房、版本、权重、分组）} 写入注册中心（Nacos/Etcd/Consul/ZooKeeper）并维持心跳或长连接会话；消费方首次调用时按服务名订阅实例列表并缓存在本地，注册中心通过 watch/推送在实例变更时增量下发。发起调用时，客户端先经过路由链（机房/单元化路由、灰度标签、版本路由）筛出候选实例，再经过负载均衡选出目标，然后走序列化（Protobuf/Hessian/JSON）+ 协议编解码 + 网络传输（Netty 长连接 + 连接池 + 多路复用），服务端反序列化后按 接口名+方法名+参数签名 找到实现类执行，把结果或异常回传。整条链上还挂着超时、重试（要区分幂等与非幂等）、熔断、限流和全链路 Trace 埋点。常被追问的点：本地缓存 + 推送为什么比每次去注册中心拉更靠谱（减少注册中心压力和调用延迟，代价是短暂不一致）；实例下线为什么要先摘流量再优雅停机（等客户端缓存刷新 + 等在途请求完成）；健康检查失败多久摘除。

控制面下发流量规则与按机房比例选路：控制面负责规则的编辑、校验、存储与下发，数据面（Sidecar 或进程内 SDK）负责执行。下发的载体通常是一份带版本号的规则文档（YAML/JSON），通过长连接推送 + 定期全量拉取做兜底，数据面收到后按版本号幂等更新，失败则继续用旧版本，保证「规则坏了不影响现网」。规则内容表达的是匹配条件 + 目标权重，比如「来源服务 A、目标服务 B、标签 env=prod 时，机房 SH 权重 90、机房 BJ 权重 10」。数据面选路时按顺序执行：先做就近路由——优先选与调用方同机房的实例（避免跨机房 RTT 和专线带宽成本）；如果同机房实例不足或不健康，再按规则里的机房权重做加权随机/加权轮询；最后在同一机房内做实例级负载均衡。按比例选路的实现一般是「两段式」：先按机房权重抽机房，再在机房内按实例权重抽实例，而不是把机房比例摊到全局权重里——这样比例更稳定，也便于在线调权重。要注意的边界：比例是概率性的，小流量下实际分布会抖动，所以通常设最低流量阈值或对灰度流量做定向标签路由而非纯比例。

同机房负载均衡策略与权重：常见策略有轮询/加权轮询、随机/加权随机、最少活跃连接数、一致性哈希（用于有状态或需要缓存的场景）、最快响应（P2C，随机挑两个比一下，兼顾效果与开销）。实例权重最常用的原因是它把「实例能力差异」这一层抽象出来了：不同机型（CPU 核数、内存、是否带本地 SSD）、不同部署形态（容器 vs 物理机）、不同版本（新版本灰度期给低权重）、以及故障恢复中的实例（刚重启的 JVM 还在 JIT 预热）都能通过调权重精确控制流量，而不必改路由规则；同时权重可以动态下发，运维能在秒级完成摘流和回补。回答时要补一句：静态权重只解决「配置层面」，真正让流量合理还需要配合自适应负载均衡（按实际 RT 和负载反馈调整），否则机型差异导致的慢实例会一直拖长尾延迟。

机型与规格如何影响吞吐与流量分配：吞吐主要由 CPU 核数（决定并行度）、内存（决定堆大小与 GC 频率）、网络带宽、以及是否有本地盘/加速卡决定。同样的服务跑在 4C8G 和 16C32G 上，QPS 上限可能差 3～4 倍；JVM 应用还要看 GC：内存小的实例 Full GC 更频繁，长尾延迟更差。所以容量规划上先做压测给每种机型标定一个「安全水位」，把它折算成权重（比如以 4C8G = 100 为基准，16C32G 给 350～400 而不是线性 400，留出余量），再按权重分配流量。还要注意两点：CPU 限流（容器 cgroup quota）会让实例在高负载时被 throttle，表现为 RT 突然抬升，这类实例要能被健康检查或自适应算法快速降权；异构机型混部时，最慢的实例决定集群的长尾，所以要么统一机型，要么让大规格实例承担更多流量。

Agent 做规范治理的边界：让 Agent 先做「创建和管理流水线」而不是直接执行治理节点，是典型的风险分级策略。原因清楚：流水线本身是幂等、可审计、失败影响面可控的操作（创建出来不跑就不生效），而执行治理节点会真实改动线上配置或重启服务，属于不可逆、影响面大、需要回滚预案的动作。要能答出放开边界的条件：一是可观测性完备（每个治理动作都有明确的前置校验、执行日志、效果指标和自动回滚点）；二是回滚能力经过实战演练（能在分钟内恢复，且回滚本身也是自动的）；三是权限与审批链明确（谁授权、什么范围、是否需要人工确认）；四是评测体系能证明 Agent 在离线场景的决策准确率稳定达标（比如连续多个迭代期无高危误判）。另外要强调人工闸门的设计：高风险动作保留人工确认（human-in-the-loop），Agent 负责生成方案、执行低风险批次和全程监控。

批量发起、监控与紧急回滚：批量治理要做成「分批 + 灰度 + 熔断」。发起时按业务/机房/集群分组，先跑 1% 的批次观察关键指标（错误率、RT、CPU、下游依赖健康度），达标再逐级放量；每批之间留观察窗口而不是一波推平。监控上要订阅执行状态（流水线状态机 + 回调/webhook），同时对比变更前后的 SLO 指标做异常检测（阈值 + 同环比），并设置「变更窗口内任何 SLO 恶化都自动暂停后续批次」。紧急回滚要满足三点：回滚脚本预先存在并定期演练、回滚幂等（重复执行不会造成二次破坏）、回滚触发条件量化（比如错误率连续 1 分钟超过基线 3 倍即自动触发，而不依赖人看盘）。事后要固化：把这次异常写成新的检测规则和评测用例，避免同一个坑再踩。

Agent Runtime 选型：回答时按评估维度讲对比过程，而不是只报一个框架名。维度包括：编排模型（图/状态机 vs 链式 vs 事件驱动）、状态持久化与断点续跑能力、工具与 MCP 生态兼容性、可观测性（OpenTelemetry/LangSmith 集成）、流式输出与中断恢复、多语言支持、许可证与社区活跃度、以及部署形态（是否有服务端组件、能不能内网私有化）。常见候选是 LangGraph（图式状态机、适合复杂条件分支和人工介入）、LangChain（生态全但抽象重）、AutoGen/CrewAI（多 Agent 协作）、以及自研轻量运行时（可控、依赖少）。结论要落到「我们最看重哪两点，因此选了哪个，代价是什么」。

收集真实用户反馈与 Use Case：渠道分四类：一是产品内的显式反馈（点赞点踩、纠错入口、满意度评分），要带上下文快照否则无法复现；二是行为数据（会话轮次、重试率、中断率、人工接管率、复制/采纳率），能反映真实价值；三是人工侧的反馈（客服工单、社群、内部试用者的 case 收集），质量高但量少；四是线上 badcase 自动挖掘（用规则筛低置信度、格式校验失败、工具调用异常的会话）。收集后要做闭环：给每个 case 打标签（场景、失败类型、严重级别）进样本库，定期筛选进评测集，并跟踪修复后的回归结果。关键是别只收集「用户说好」的，负反馈才是评测集的主要来源。

评测体系：确定性指标与 Review Agent 指标：确定性指标是能用代码判定的，例如任务是否成功完成、输出是否符合 JSON Schema、引用的文档是否存在且匹配、是否调用了禁用工具、token/调用次数是否超预算、耗时是否超阈值、以及答案中的关键事实能否在给定上下文里找到出处。Review Agent 指标是用模型或人工打分的，例如回答的有用性、完整性、语气、推理链是否合理、是否答非所问，通常按 1～5 分或成对偏好（A/B 更好）来评。汇总方式要避免简单平均：先给每类指标设权重（确定性的硬门禁类指标用一票否决或门槛制，质量类加权），再按维度加权求得总分，同时保留明细便于定位。要强调两点工程细节：Review Agent 的模型与提示词必须冻结版本，否则分数不可比；人工抽检要固定比例（比如 10%～20%）用来校正自动打分的偏差。

阈值怎么定、为什么盯高风险问题：阈值定法通常是三步：先跑基线得到分布（比如 100 个基准 Case 的 token 消耗中位数与 P95），再按成本预算和业务容忍度选阈值（一般卡在 P95 或 P99，而不是平均值，因为长尾才是体验和成本的痛点），最后上线后持续跟踪并按误报率调整。优先关注「禁止工具调用」这类高风险问题的原因是代价不对称：token 超一点只是钱，误调用删除/写库/发消息类工具是数据事故，一次事故的成本远超大量轻微超标的累计损失。所以评测里高风险项应当是硬性门禁（fail-fast），质量项才是打分项。

RAG 如何提高准确性与速度、管控检索流程：准确性方面：切分策略要按语义（标题层级、段落）而不是固定长度，保留重叠避免截断；为每个 chunk 补元数据（文档、章节、时间、权限标签）；检索用混合召回（向量 + BM25 关键词），再上 rerank 模型精排；对 query 做改写/扩展（HyDE、多路改写）和意图识别，把简单问题直接走关键词；必要时做父子块（小块召回、大块喂给模型）和上下文压缩，减少无关内容干扰。速度方面：向量索引用 HNSW/IVF 并调参、缓存高频 query 的结果、并行召回多路、限制 top-k 并在 rerank 后截断、embedding 批量预计算、把检索和生成解耦异步化。管控整条执行链路的手段是把它显式建成「流程」：定义每个阶段（改写 → 召回 → 过滤 → 精排 → 组装 → 生成 → 引用校验）的输入输出契约和超时预算，全链路 trace 记录每阶段耗时与命中结果，权限过滤必须在检索阶段做而不是生成后再删，最后强制引用出处并对无出处的回答降级为「未找到依据」。

AI Code Review Skill 的设计关注点：可以从「审什么、怎么审、怎么不烦人」三层讲。审什么：按优先级分层——正确性与边界（空值、越界、异常吞噬、并发与锁、事务边界）、安全（注入、越权、密钥硬编码、SSRF、反序列化）、性能（N+1 查询、循环内 IO、大对象、缺索引的 SQL）、可维护性（命名、重复、过长函数、缺测试）、以及仓库约定（分层、错误码、日志规范）。怎么审：把规则分成确定性检查（lint/SAST/自定义 AST 规则，先跑，成本低且零幻觉）和模型评审（读 diff + 上下文文件 + 相关历史提交，输出结构化意见）；上下文要给足（不只 diff，还要相关文件、接口定义、仓库规范文档），否则误报率高。怎么不烦人：每条意见要带严重级别、文件行号、具体改法建议，并允许作者标记「忽略」且忽略要能反馈回规则；同时设噪声预算（一次评论超过 N 条就只保留高优先级），避免狼来了。工程细节还有：只对增量 diff 评审、跳过生成代码和 lock 文件、敏感代码不外发、成本可控（缓存文件摘要避免重复分析）。