本篇属于 智能体面试与工程基础 系列。
A37｜P0：Trace应该记录什么？
口述： 用trace/span表达一次请求及嵌套调用，关联session_id、run_id、agent、step、工具调用ID、状态、耗时、token、成本与重试原因。记录必要且脱敏的输入输出引用；日志不是把全部上下文或密钥原样落盘。OpenTelemetry Traces
追问： 跨消息队列如何传播关联信息，跨Session如何找到同一业务任务？
指标口径： 工具调用成功率分别统计“单次attempt成功”与“业务操作最终成功”，重试会改变分母。Token按输入、输出及供应商支持的缓存口径记录，成本按实际计费规则核算。失败样本脱敏后保留输入、模型/提示/工具版本与结果引用，进入可回放评测集；需要限制真实副作用，不能回放时再发一次短信。
A38｜P0：RAG与Agent如何评测？
口述： 建立代表性任务、答案或验收条件，分开发调参与保留测试；检索看命中与排序，生成看证据支持与答案正确，Agent看最终任务成功、工具错误、成本与延迟。Hit@K与Recall@K定义不同，Faithfulness不等于事实正确，LLM评委需人工校准。
追问： 参考文档本身错了，忠实回答该得什么分？使用 RAGAS 等评测工具时，需要明确指标定义、版本和评委模型。
A39｜P0：如何减少幻觉与做故障回归？
口述： 区分知识缺失、检索错误、证据误读和工具结果伪造，再分别处理。提供可靠证据、校验结构与来源、允许澄清或拒答、加入故障注入回归；RAG和低温采样都不保证消除幻觉。
追问： 检索正确而答案错误时，只增加top_k是否可能更差？
Bad Case 复盘： 先保存可重放的输入、版本和trace，找到预期与实际首次分叉的位置。逐层替换已知正确的路由、检索证据或工具结果，区分模型选择错误与系统执行错误；一次改一个主要变量，验证修复是否解决目标案例及同类问题，再检查旧回归集有无退化。只展示修好的一条日志不能证明普遍改进。
A40｜P0：项目难点、失败案例、技术选择怎样回答？
口述模板： 当时要解决什么→约束是什么→我做了什么→对照和实际结果→仍有何不足。没有做过的技术说“了解原理、尚未实装”，教学案例可以用来解释设计，但应与自己的实际经历区分。
追问： 给出一条失败日志或代码提交；如果重做，哪里会简化？
A48｜P1：带两三个人做 Agent 模块，如何拆任务与控制交付？
口述： 先对齐用户任务、验收集、权限和延迟成本边界。按可独立验收的模块拆分，例如运行时/工具契约、检索/数据、服务/观测，同时明确跨模块负责人。尽早打通一条真实端到端路径，再补故障恢复和质量优化，避免各自“模块完成”却无法集成。
里程碑示例： 第一阶段形成最小链路与trace；第二阶段通过超时、重复请求、取消及权限测试；第三阶段完成代表性评测与灰度回滚。Code Review 检查输入输出契约、幂等和副作用、上下文与凭证处理、资源释放、可观测性和失败测试，不能只看正常路径能跑。
需求模糊且工期紧： 用具体正反例澄清“支持新能力”的含义，列出最小可交付范围、依赖与暂不承诺的边界。对高不确定环节做有时间上限的验证，提供分阶段方案；不把模型演示成功一次当成可靠性承诺。
追问： 最后一周质量仍未达标，是缩范围、走固定流程、人工兜底还是延期？按用户影响与证据决策；没有带队经历时，明确这是设计方案。
A49｜P1：如何跟进新技术，并判断是否值得引入？
口述： 从论文原文、官方文档、源码、release notes和issue跟踪方法与限制，把技术博客作为线索。选择一个与当前问题有关的具体方法，讲清问题、机制、证据、限制与自己验证到哪一步，不能只报模型或框架名字。
验证步骤： 固定已有基线、代表性任务和预算，先做小规模复现或兼容性验证，再比较质量、尾延迟、成本及维护复杂度。比如评估HyDE时，保留原query通道，观察领域词查询收益与错误假设造成的漂移；不要预设一定有提升。
决策输出： 采用、限场景试用或暂不采用，都要对应具体证据。面试中的“最近学了什么”可以使用自己实际读过的ReAct或检索论文，但阅读、复现和生产上线是三个不同的完成程度。
