字节 260901 一面面经

《面试题目》

1. 做过哪些 Agent 迭代？如何衡量改动效果？
2. 修好一类 bad case 后，如何发现其他场景是否退化？
3. 评测只看最终答案，还是也检查意图识别、工具选择与调用轨迹？
4. 人工标注的问答评测集如何自动化执行和判分？
5. 原有文档切分有什么问题，为什么按标题组织内容？
6. 规章制度文档可能并不长，为什么还需要切片？
7. 如果已经检索到相关文档，为什么不直接把整篇文档输入模型？
8. 是否实际比较过整篇输入与切片方案？
9. 是否统计过线上有效会话？
10. 真实用户的表现与离线评测结果有什么差异？
11. 如何收集和分析用户负反馈？
12. 如何把线上错例回流到评测集？
13. 是否做过答案自动标注？
14. 简单问答与 Coding Agent、长程任务的评测有什么不同？
15. 对复杂执行链和复杂产物，如何观察线上效果？
16. 只看最终结果是否足够？
17. 详细讲一下你的个人项目。
18. 同一查询词可能对应成语、电影、歌曲等不同对象，如何判断用户真正想找什么？
19. 除了语义检索，还能结合哪些信息提高意图判断的准确性？
20. 手写 Agent Loop、使用图编排框架、使用更完整的 Agent SDK 或 Harness，各有什么取舍？
21. 选型前做过哪些调研？
22. 上下文压缩、工具调用与调试能力，是自己实现还是复用现有框架？
23. 如果要评估一个覆盖问答、文档、创作等场景的通用 Agent，会怎样拆解任务？
24. 如何利用线上反馈和运行轨迹判断表现？
25. 两个产品的用户输入不同，如何控制变量、进行公平比较？
26. 无法获得竞品后台数据时，如何开展比较？
27. 执行时间长是否一定代表异常？不同任务是否应使用同一规则？
28. 手撕：实现一个类，支持 insert(word) 插入单词、search(word) 判断完整单词是否存在、startsWith(prefix) 判断是否存在指定前缀。
29. 手撕：输入为两个升序数组，输出合并后的降序数组，要求 O(n)。

《参考解析》

Agent 迭代与回归评测：Agent 的改动（提示词、工具描述、模型版本、检索参数）天然全链路耦合，所以每次迭代都要用固定评测集跑回归。做法是先把线上真实请求抽样成集，标注期望行为——不只是最终答案，还包括该调用哪些工具、关键参数是什么；每次改动跑全量或分层抽样，比对通过率、平均步数、工具调用成功率、token 与延迟。「修好一类 bad case 会不会打坏别的」要靠分层指标回答：按意图或任务类型分组统计，只看总分会被涨跌互相抵消掩盖，某一组掉幅超过阈值就回滚。评测集要持续扩充，把线上新错例补进去，否则几个月后它只覆盖老问题。

评测看最终答案还是看轨迹：只看答案会漏掉「答对了但过程错」——工具选错却瞎猜对了、检索用了无关文档但答案恰好正确，这类成功不可复现，下次就翻车。所以要拆成可独立观测的几层：意图识别是否正确、工具选择与参数是否正确、调用顺序与步数是否合理、最终答案是否忠实于检索结果。轨迹断言的可落地形式是软断言——期望工具集合、关键参数包含关系、步数上限，而不是逐字比对；答案层用模型打分加人工抽检校准。前提是每步的工具、参数、返回摘要、耗时都落库，没有日志就谈不上评测。

切分的必要性与长上下文：即便文档不长，切片也有三个作用：把检索单元和生成单元解耦，命中的是具体小节而不是整篇，上下文噪声更少；文档按标题组织，天然对应用户问题的粒度，问哪条制度就召回哪一节；召回可以带出处，答案可回溯，还能按节做增量更新，改一条不用重刷整篇。那为什么不整篇塞模型：规章类文档虽短，一次召回的往往是三五篇，长上下文下模型对中段信息的利用会明显下降，token 成本与延迟线性上涨，还容易把不相关条款混进答案。合理链路是「粗召回整篇 → 细粒度挑节 → 按 token 预算拼接」，并且用同一份评测集真的做过整篇输入与切片方案的对比，而不是靠直觉。

线上观测与错例回流：先把「有效会话」定义清楚——排除测试流量、用户没提问就关闭的、一次就走的闲聊，否则指标会被噪声稀释。线上看过程与结果两类：无结果率、追问率、放弃率、点赞点踩、平均轮次、工具失败率、P95 延迟；再和离线评测对齐，看偏差在哪——常见偏差是线下题目太干净，线上口语化、带错别字，召回率虚高。错例回流要有固定管道：负反馈与「无结果」的会话自动进候选池，人工过一遍并标注归因（意图 / 召回 / 生成 / 资料缺失），再合入评测集。答案自动标注只能当预填，让模型先给候选标签、人只做确认，否则错标会污染整个回归基线。

长程任务与复杂产物怎么评：区别在于结果不是一个字符串。Coding Agent 的产物是可运行的程序，用编译、单测、lint 当客观判据；长程任务的产物是「多步执行链加中间态」，判据随之变成过程与状态：关键步骤有没有做到、中间产物是否符合约束、有没有绕过约束走捷径、失败后能不能恢复。所以评测分三层——终态检查（文件是否生成、测试是否通过）、过程检查（步骤与工具轨迹是否符合预期、有没有多余调用）、质量检查（产物本身的可用性与格式）。线上观测尤其难，因为一条会话可能跑很久、用户中途关掉；可行做法是按任务类型埋关键里程碑事件，统计到达率与耗时分布，对超时或中途退出的会话单独归因，而不是一律算失败。

Agent 框架选型：手写 Loop 完全可控、无黑盒、依赖少，但状态机、重试、并发、可观测、上下文管理都得自己写，异常路径容易出坑。图编排框架把流程显式建成节点与边，条件分支、并行、回滚、持久化与恢复都是现成的，适合步骤结构明确的场景，代价是抽象层带来调试成本，遇到框架没覆盖的需求会拧巴。完整的 Agent SDK 或 Harness 提供现成的工具循环、记忆、子 Agent、沙箱与追踪，上手最快，代价是约定多、版本迭代快、出问题只能等上游，还容易被它的默认行为绑住。判据是先问流程是否可枚举，可枚举就上图编排；再问团队要不要长期维护这套骨架，要就自己写核心循环、只借工具。选型前的调研包括读文档与源码、翻 issue 里的高频坑、用一个真实任务做验证、评估可观测与测试的接入成本。

通用 Agent 的竞品公平比较：拿不到对方后台数据时，唯一能控制变量的办法是自建题集和统一入口。构造一份覆盖问答、文档、创作等场景的题目集，两端用完全相同的方式提问（同样的提示、同样的轮次限制，记录完整输出与耗时），再用同一套脚本离线判分；评分拆成客观项（格式、事实一致性、是否按要求输出）与主观项（隐藏产品名、随机顺序、多人盲评取一致性）。要特别注意「执行时间长不一定异常」：长任务天然慢，延迟应该按任务类型分别看分位数，而不是所有任务用同一阈值；同理，两端默认开启的能力（联网、文件解析、多轮澄清）不同，也要拉齐条件，否则比的是配置而不是能力。

手撕：前缀树：节点用 children: Map<char, Node> 加一个 isEnd 布尔。insert 逐字符向下建节点、末尾置 isEnd；search 沿字符走到底后返回「节点存在且 isEnd 为真」；startsWith 只要路径走通就为真。三者时间都是 O(L)，空间是所有词的总字符数。用 Map 比定长数组省空间、也支持任意字符集；查询量极大时可以上压缩形式（radix trie 或双数组 trie）。

手撕：两个升序数组合并成降序，O(n)：双指针从两个数组末尾往前取较大者，从结果数组末尾往前填；也可以从头部取较小者填入结果、最后整体反转。两个数组各自有序，归并本身是 O(n+m)，没有排序因此不是 O(n log n)。边界要说清：一个数组先走完就把另一个整体接上，注意重复元素和空数组。追问常是能不能原地——如果其中一个数组尾部预留了空间，从后往前填就能原地归并。