CVTE 视源股份应用开发一面：LLM 评测体系与 Agent 架构演进 28 问

《面试题目》

自我介绍与项目背景

1. 请做一个简单的自我介绍，讲一下实习项目与经历，以及在项目中承担的角色。

大模型评测体系设计

2. 简历里提到日志分析准确率从 29% 提升到 68%、综合达到 83%，并构建了评测体系。你具体负责哪部分？这个评测体系是怎么设计和落地的？
3. 标准测试 Case 包含用户描述、系统日志等，还涉及多维度权重和人工复核。这些部分的标准、评分量表和流程是怎么设计的？Case 模版怎么跟业务工程团队对接收集？
4. 目前这个评测集的样本（Top 20 典型 Case）对真实线上数据问题的覆盖率是多少？
5. 每个 Case 运行多次会有随机性，目前用什么方式解决大模型输出的随机性影响？
6. 模型迭代很快，如果模型升级后部分 Case 的返回结果与之前的预期出现差异，让你定位这个问题，你会怎么做？

Agent 工程抽象、并行优化与异常兜底

7. 如果要构建一个全新的、与当前日志分析完全不同的 Agent 场景（客服满意度分析、问答助手或工作流类 Agent），现有工程里哪些模块可以抽象复用？哪些不用动，哪些要按场景微调？
8. 简历里分析了 Agent 耗时问题并提到「增加最大 10 并发」（单轮 ReAct 多工具并行分流调用），能展开讲背景和实现吗？
9. 多工具并行调用时，如果对返回结果有顺序性要求，你会怎么处理？
10. 并行调用时如果一半结果正常返回、一半失败，你们怎么处理？
11. 如果采用退避重试，重试三次后依然失败，最终给到上层的结果怎么处理？
12. 如果不是报错而是请求超时（服务端一直不返回），你会怎么处理？并发压力达到阈值导致死锁或变慢怎么考虑？工具调用的可观测性怎么建设？
13. 做完多工具并行拆分后，分析流程的耗时优化效果怎么样？线上偶发又退化回优化前的耗时，你会怎么排查？
14. 工具拉数据时如果单次拉取超大量级日志，上下文怎么管理？如何剔除无效干扰信息、防止模型重复调用无效工具？

AI Coding 研发流程与工程规范

15. 日常研发中拿到一个编程任务，你使用 AI Coding 的工作模式和完整流程是什么样的？
16. AI Coding 经常在代码里挖坑（漏实现、性能问题、内存泄漏、安全或权限问题），你遇到过哪些？发现后怎么验证和处理？
17. 对已经踩过的严重问题，有没有工程措施避免同类问题再次出现？如果做全局约束规范（如 .clauderc.md），约束主要分哪几大类？

Agent 架构演进与技术选型

18. 架构从最初的「分类器 + 专家工作流 + 兜底 Agent」演进为「自主调用 Skills」、再到现在「双 Agent + 裁决 Agent」，讲一下这个变革过程、背景和当时的技术决策。
19. 原架构存在分类边界不清的问题，改成 Skills 自主调用的具体好处在哪里？
20. 从「分类器 + 专家工作流」变成动态加载 Skills 的模式，优点和缺点分别是什么（准确率与 ReAct 轮次耗时、成本的权衡）？
21. 如果基座模型更强了，或者业务对成本和响应时间有严格要求，你还会继续用现在的方案吗？
22. 如果分类标准本身定义不清楚，换成「双 Agent + 裁决 Agent」就能解决分类不准吗？新架构解决的核心痛点是系统扩展性，还是长链路推理与证据验证的准确率？

其他实习经历与前沿视野

23. 另一段实习里基于 n8n 二开的数据中台/工作流项目，你负责哪些模块？有没有真实的线上问题定位，讲一下过程。
24. 日常除了工作内容，还会关注哪些前沿技术方向？
25. 关注前沿模型和开源 Agent 项目时，有没有去了解它们的设计原理（自动沉淀 Skill、记忆机制），并尝试应用到自己的项目？为什么某些机制适合个人通用 Agent，却不适合直接照搬到垂直业务 Agent？

手撕代码（15 分钟在线编程）

26. 有序链表去重，保留一个重复元素（同 LeetCode 83）。
27. Follow-up：如果要求「重复出现过的元素全部删除、一个都不保留」（同 LeetCode 82），原有思路要怎么调整？

《参考解析》

评测体系：把「感觉变好了」变成可复现的数字

面试官连问五题，说明他要的是完整闭环而不是一个准确率数字。可用的结构：样本来源（线上真实 case 采样 + 专家挑的典型 case，按业务场景与错误类型分层）、标注规范（每个 case 明确输入、期望输出、评分维度，比如字段完整性、数值正确性、结论可执行性，各维度给权重和判分档位）、运行协议（温度与随机性固定、同一 case 跑多次取一致率）、人工复核（低置信度样本转人审，人审结果回流成新样本）。29%→68%→83% 这种提升要能拆开讲：哪一部分来自数据清洗、哪一部分来自 prompt 或流程改造、哪一部分来自评测口径变化——如果口径变过，必须说明。

覆盖率那题要诚实：Top 20 典型 case 覆盖的是高频错误类型，对长尾问题的覆盖率天然低。可回答「按线上错误类型的分布算，这 20 个覆盖了约 X% 的工单；长尾部分靠线上抽检补充」。

随机性怎么处理：三点。一是同一 case 多次运行看一致性，把「稳定正确」「时而正确」「稳定错误」分开统计，只有后面两类进优化清单；二是关键字段用结构化输出（JSON schema 或受限解码），把自由文本的方差压下去；三是评测结论用统计量而不是单次结果（通过率 + 置信区间），避免被一次抽样带偏。模型升级后 case 结果出现差异的定位顺序：先确认是模型变化还是 prompt/依赖变化（版本锁定与 diff），再按错误类型聚类看是「新错」还是「旧的错被修好了」，最后决定是调 prompt、补样本还是换模型。

并行工具调用：顺序、失败、超时、上下文

顺序性问题分两种：如果只是结果展示顺序，等所有结果回来按原始顺序组装即可（并行执行、串行拼装）；如果有数据依赖（后一个工具需要前一个的输出），那就不能并行，应该显式建依赖图，只并行无依赖的分支。一半失败的处理原则是「部分可用优于整体失败」：成功的部分先入库并标记完整度，失败的按错误类型决定重试（幂等才重试）或降级（用缓存/上一版数据并标注），最后把缺失项作为结构化字段交给上层，让模型或人决定是否补。重试三次仍失败，返回一个明确的失败结果对象（错误码、已尝试次数、建议动作），而不是抛异常让整条链崩。

超时与并发压垮的处理：给每个工具调用设超时 + 熔断（连续失败就短路一段时间），并发用信号量或线程池限流，避免把下游打满导致雪崩；可观测性至少要有每次调用的 trace id、工具名、耗时、状态码、重试次数、token 消耗，按工具维度看 P95 耗时和失败率。耗时退化排查就靠这套指标：先看是哪个工具变慢、还是某类输入变长导致轮次变多，再决定是加缓存、改并发还是收紧上下文。

上下文管理：单次拉取超大日志时，先做确定性过滤（按级别、时间窗、关键词、去重），再分段摘要（map-reduce 式），只把摘要和少量原始片段喂给模型；防重复调用无效工具的办法是维护一个「已调用工具 + 参数 + 结果摘要」的清单放进上下文，并在工具描述里写明前置条件，让模型看到「这个工具刚被调用过且结果为空」。

架构演进：把每次改造的动因说清楚

这道题的问法很专业——它要求你回答「解决了什么」而不是「用了什么」。可用的叙事：第一阶段分类器加专家工作流，优点是路径确定、成本可控，缺点是分类边界一模糊就整条走错，而且新增场景要加一个专家流；第二阶段改成 Skills 自主调用，把「选流程」交给模型，扩展性变好、但 ReAct 轮次变多、耗时和成本上升；第三阶段双 Agent 加裁决，用两个视角交叉验证再由裁决方定结论，针对的是长链路推理的证据可靠性。接着主动说代价：轮次多意味着延迟高、token 贵，所以只在证据要求高的场景开双路，简单场景仍走单路。最后回答「模型更强了还用不用」：模型变强会削弱「分类」的必要性，但不会消除「证据校验」，所以架构的重心会从流程编排转向验证与可观测性。

AI Coding 的工程约束

流程上讲清四步：先让 AI 读上下文并产出计划（改哪些文件、为什么），人审计划；再小步实现，每次只改一个可验证的单元；然后跑测试与 lint，自己 review diff；最后提交前检查有没有偷偷改掉无关代码、有没有引入依赖、有没有把错误吞掉。常见坑按类列：漏实现（只写了 happy path）、性能（N+1 查询、循环里发请求）、内存与资源（没关 fd/连接）、安全（把用户输入直接拼进 SQL 或命令）。防复发靠三类约束：项目级规范文件（架构约定、禁止事项）、自动化门禁（lint、类型检查、测试）、以及把踩过的坑写成可检索的记录。

手撕链表去重

LeetCode 83 用单指针：cur 从 head 开始，若 cur.next.val == cur.val 就 cur.next = cur.next.next，否则 cur = cur.next。LeetCode 82 需要哑节点和前驱：prev 指向哑节点，cur 指向 head，当发现 cur 与 cur.next 值相同就记住该值、把所有等于它的节点跳掉，然后 prev.next = cur；否则 prev = cur、cur = cur.next。讲的时候主动说边界：空链表、全相同、只有一个节点、以及 82 里「跳完之后 cur 可能为空」。面试官让你口述，重点是把指针移动的每一步说清楚，而不是背代码。