AI Agent 开发工程师面经

1、你的项目需要等待模型生成内容。流式输出能解决什么问题？首字延迟和总耗时应该怎么区分？

流式输出让客户端在完整响应结束前接收部分内容，主要改善开始等待时的体验。首字延迟关注发起请求后多久收到首个可展示内容，总耗时关注整个结果多久完成；连接建立成功、收到心跳和收到正文也应区分。流式可以让用户更早看到进展，但不保证模型总生成时间更短。

对摘要，前面的完整句子有一定阅读价值，可以逐步展示；对五道单选题组成的测验，看到第一题不等于整份测验已经可提交。我的处理思路是把预览与正式结果区分开，结束后检查题数和内容，再把完整测验交给用户使用。排查“响应慢”时也先确定用户指的是一直没内容，还是已有内容却迟迟不结束，这两种现象的检查方向不同。

2、如果流式返回 JSON，你能每收到一段就 json.loads 吗？怎么判断它完整结束了？

通常不能。网络分块与 JSON 对象边界没有必然关系，一段可能停在字段名、字符串或转义字符中间。某些协议还会发送非文本事件，需要先按接口协议识别事件和内容增量，再处理业务数据，不能把所有收到的字节都当成正文拼接。

对规模较小的测验，可以累积文本，在确认正常结束后整体解析和校验，界面只显示进度或标注为未完成的预览。如果要提前展示题目，需要支持增量解析，并明确一题什么时候闭合；不能简单数大括号，因为字符串本身也可能包含括号。即使当前片段碰巧能解析，也不能据此认定整个任务成功，还要检查结束原因：正常完成、达到输出上限和连接中断对应不同状态。正式保存应在整体业务校验通过之后进行。

3、如果流式生成到一半中断，能让模型“接着写”，然后把新文本拼到原来后面吗？重新生成和断点续传有什么区别？

不能把一句“接着写”当成可靠的断点续传。真正续传需要服务提供继续读取同一次结果的机制，例如持久化任务及可恢复的事件位置；具体是否支持，要查对应接口。重新发起模型请求一般是一次新的生成，它未必保留原来的内部状态，也可能重复开头、改变题目顺序，甚至改掉先前的答案。

对五题规模的测验，如果接口不支持恢复，整份重新生成并重新校验通常更容易保证一致性。如果已经有若干完整且通过检查的题，也可以明确保留这些题，再单独生成缺少的题，最后做去重、题数和知识点覆盖检查。但这已经是应用层的组合流程，不是原始 JSON 字节流自然接续。界面应替换或重新组织草稿，避免把两次响应直接拼接后宣布完成。还要限制尝试次数，防止恢复逻辑不断产生新请求。

4、结果完整拿到了，接下来谈正确性。你的助手为什么用程序判断单选答案，却只把模型的简答反馈当学习建议？

单选题在标准答案已核对、选项顺序固定时，程序直接比较选项标识就能得到确定结果，容易复现和测试。让模型重新判断每一次选择，反而增加不稳定性与成本。但这只保证执行既定标准：如果生成的标准答案错了，程序会稳定地判错，因此生成题目时还需要检查依据和选项歧义。

简答题有多种正确表述，完全字符串匹配过于严格，需要依据知识要点、必要条件和可接受的同义表达判断。可以给模型评分规则，并要求指出满足或缺失的要点以及相关证据，便于复核。不能仅凭模型声称“很确定”就把反馈当正式成绩。项目定位是学习辅助，可以保留争议反馈并人工检查，不需要假设自己已经解决严肃考试的自动评分问题。

5、要评估刚才说的简答判断，只看准确率够吗？假设100份答案里只有10份实际有错，全判正确会发生什么？

全判正确仍有90%的准确率，但一个错误都没找出来，说明类别不平衡时准确率可能掩盖核心问题。先把“实际有错”设为正类：精确率看被标为错误的答案中有多少真的错，召回率看全部错误答案中有多少被找出。

假设系统标出八份错误，其中六份确实错，那么精确率为6/8=75%，召回率为6/10=60%；误报两份、漏报四份，准确率为94%。这是教学算例，不是项目实测。对学习反馈，误报可能误导学生，漏报则会放过误解，要同时观察两者以及具体错误类型。还应按知识点和答案长短查看失败样本。评估标签本身要有可复核的判断依据，否则指标只是在比较两份不可靠的答案。

6、根据这些失败样本修改提示词以后，原来那批题效果明显变好了，能说明方法更有效吗？

只能说明它更适合被反复查看的这批样本，还需要独立样本验证。即使没有训练模型参数，开发者不断参考同一批结果调整提示词，也可能把规则写成只照顾这些题的特例。这里与过拟合的共同点，是把针对已见样本的改善误当成对新样本的泛化。

我会区分调试集与保留的测试集。课程材料容易出现同一题换个说法就重复出现，因此应按章节或资料来源合理分组，避免近似题跨集合泄漏；具体分法要匹配将来是处理新章节，还是同章节的新问法。比较新旧提示词时固定模型版本、输入与其他配置，必要时重复运行观察波动。还要查看改善的是漏报还是误报，不能只报一个总分。几道题提高一两分不足以支持稳定提升的结论。

7、这些评估要调用真实模型，但日常开发不能每改一行都跑一遍。Mock 测试和真实模型评估分别验证什么？

Mock 测试验证程序面对指定响应时是否处理正确。例如预设正常结果、字段缺失、拒绝、超时和流中断，检查程序会不会误保存、能不能返回合适状态。它的价值是稳定地触发分支，不是在模拟真实模型的全部行为。正常响应全部由开发者写好，即使测试全过，也证明不了模型会生成正确题目。

真实接口集成测试主要确认请求、事件解析和参数仍能对接；内容评估则使用带判断依据的样本，检查出题和反馈质量。两者可以共用部分样本，但结论不同。我会把模型调用放在可替换的适配层，日常先运行确定性逻辑测试；修改提示词或模型配置时，再运行相应内容评估。这样一旦质量变差，可以区分是程序解析出了错，还是模型本身给出了不合格内容。

8、查询之外，保存测验要写主表和题目明细。事务应该覆盖哪些步骤？为什么不把模型生成也包在事务里？

事务应覆盖需要共同成功的数据库操作，例如插入一条测验记录和它的全部题目明细。完整题目先生成并完成结构、业务校验，再开启事务写入；所有写入成功后提交，发生异常则回滚，避免主表存在但明细只有一部分。事务的原子性约束写入整体，业务一致性还依赖正确的代码和数据库约束。

模型网络调用通常耗时更长，而且不能通过数据库回滚撤销已经发生的推理和费用。把它放在写事务里，既不会获得跨模型服务的原子性，还会延长数据库写入占用。在 SQLite 中同时只能有一个写事务，这个代价更明显。对本项目，把生成、校验和短事务保存分开就足够；不需要为了“所有东西放一起”引入更大的事务范围。SQLite 事务说明

9、如果两个用户几乎同时保存，SQLite 使用 WAL 模式就能让它们同时写了吗？该怎样处理忙锁？

不能。WAL 改善的是读写并发：读取可以使用对应快照，写入追加到日志，读者与写者能够更多地并行，但仍然只有一个写者。它不是把 SQLite 变成任意多写事务同时执行的数据库。校招回答重点是分清“读写互不阻塞的能力有所改善”和“多个写者并行”不是一回事。SQLite WAL 文档

遇到数据库忙，先检查是不是事务太长、连接没有及时提交或回滚，再考虑设置合理的忙等待超时。对于确定可重试的操作，可以在回滚当前失败尝试后，进行有限重试；如果请求是否已经提交不确定，则应结合业务请求标识查询结果，避免重复保存。课程规模先优化事务范围即可。只有明确出现持续写入竞争并影响目标需求时，再评估更适合并发写入的数据库，不能仅凭一次忙锁就决定重构。

10、最后给一个排查题：要求生成五题，页面提示成功，但重新打开只看到两题。你会先查什么，怎么判断是哪一层的问题？

我会沿同一次请求找证据，先确定数据库里到底有几题。如果数据库中有五题，重点检查读取条件、分页和前端状态；如果数据库只有两题，再对照生成结果、校验结果与保存日志。需要有请求标识串联这些信息，但日志不必记录整份私人笔记。

若模型只生成两题、程序仍把它判定为合格，问题在业务校验：合法 JSON 不等于满足五题要求。若校验时有五题，写入后却只剩两题，则检查是否逐题提交、异常被吞掉或部分写入发生在事务外。若事务完整提交了五题，也应考虑之后是否发生其他修改，不能直接认定是生成模型的问题。

修正后应做有针对性的复现：让模型桩返回只有两题的完整 JSON，确认不会显示成功；再让第三条明细写入失败，确认主表和前两题一并回滚；正常路径则检查重新查询确实返回五题。这里考察的是用证据区分模型输出、业务校验、数据库写入和页面展示，而不是遇到不完整结果就先调提示词。