联想 AI agent 应用开发一面（暑假）

元数据

作者：逸
分类：面经
抓取时间：2026-07-25T06:45:51.861Z
原文：[打开小红书笔记](https://www.xiaohongshu.com/explore/69dfb7d4000000002102fae2
互动：272 / 432 / 9

正文

长图内容（视觉重读）

由 AI 视觉重读截图整理，替代原 tesseract OCR 乱码。p02 为封面（联想 agent应用开发一面·暑期，Q1 自我介绍），p03–p15、p01 为问答长文截图，p17–p19 为表情包贴纸。截图跳页导致 Q6、Q10、Q12 的答案和 Q13 整题未被覆盖，下面如实标注。

1. 自我介绍

2. Agent 项目的架构设计如果从入口到结果回写完整讲一遍，应该覆盖哪些关键组件？

一条完整链路至少要有输入适配、会话状态、意图路由、规划执行、工具层、结果验证、记忆写入和观测闭环。输入适配把文本、语音、截图、事件流统一成内部消息；状态层管理用户、会话、任务和中间结果；路由层判断当前是闲聊、问答、执行还是追问；执行层决定单 Agent 直做还是拆给多个子 Agent；工具层负责搜索、知识库、数据库、业务 API 和外部应用；结果验证层做格式校验、权限校验和事实检查；最后写入日志、指标和长期状态。真正难的是这些组件之间的边界，不是把它们名字背出来。

3. ASR 选型怎么做，为什么不能只看字错率？

至少要同时看识别准确率、时延、领域适配能力、热词机制、标点和断句质量、说话人分离能力、部署成本以及和后续 Agent 的耦合程度。很多场景里字错率不是最关键的，真正影响 Agent 体验的是实体词识别、数字时间识别、流式稳定性和 partial hypothesis 的抖动。会议助手漏掉专有名词和客户名称的代价远高于普通口语错误；车机语音则端到端延迟和打断恢复比极限精度更重要。

4. 流式 ASR 的最低可用延迟通常由哪些环节决定，怎么把延迟压下去？

最低可用延迟不是单点数字，而是采样窗口、特征提取、模型前向、端点检测、解码策略、网络传输和 UI 刷新共同叠加的结果。压低延迟通常会缩短 chunk 长度、优化增量解码、减少 beam、做缓存复用、提前输出稳定前缀、让端点检测和识别并行，并尽量减少服务端排队。注意延迟和稳定性互相拉扯：chunk 太短会让 partial transcript 来回抖动，后面的 Agent 状态机会被扰乱。

5. 非流式 ASR 和流式 ASR 的根本差别是什么，只用非流式行不行？

非流式 ASR 在看到完整音频后再统一解码，上下文更完整、识别精度更高、容易做全局重打分；流式 ASR 必须边听边出，很多决策只能基于局部上下文做近似。只用非流式是否可行取决于业务时延上限：离线质检、录音归档、会后总结完全可以；实时助手、边说边查、同声字幕或需要即时反馈的场景基本不可接受，因为交互已经断了。

6. 主 Agent 的意图识别到底应该怎么做，为什么单轮分类器经常不够用？

（答案未被截图覆盖）

7. 主 Agent 和子 Agent 的模型该怎么分配，为什么不一样？

主 Agent 更像调度器，需要稳定的任务理解、状态管理和路由能力；子 Agent 更像执行器，可能偏检索、偏代码、偏表格、偏总结或偏多轮对话。用同一个大模型方便，但成本、时延和能力结构未必合理。工程上常见做法是主 Agent 用更稳的大模型做高层决策，某些子 Agent 用小模型或专门模型做垂直任务（分类、排序、结构抽取、OCR 纠错或 SQL 生成）。真正要讲清楚的是能力分层，而不是"参数越大越好"。

8. 用户一次提多个需求时，Agent 的任务分解应该怎么做才不会互相污染？

关键不是拆得越碎越好，而是先识别需求之间有没有依赖关系、资源冲突和共享上下文。用户同时要求"总结这段会议""查一下竞品价格""给我写个跟进邮件"，三个动作输入产出不同，最好拆成独立子任务并维护各自状态；但如果第二个需求依赖第一个的产物，就要建立任务图而不是平铺队列。否则常见问题就是一个子任务的中间结果被另一个错误继承，最后整个会话上下文被污染。

9. Agent 的评估指标该怎么设计，为什么不能只看任务成功率？

只看任务成功率会掩盖太多问题。真正可用的评测至少要把路由正确率、工具调用成功率、参数填充正确率、平均步骤数、终局成功率、回退率、人工介入率、时延分位数和单位任务成本拆开看。同样是"成功"，可能一个系统走了 3 步、一个走了 12 步；也可能一个频繁误调工具但最后碰巧做对，另一个全程稳但极少数任务失败。Agent 的评测本质上是过程和结果一起评，而不是只看终点。

10. 上下文压缩怎么做，才能既省 token 又不伤决策？

（答案未被截图覆盖）

11. 用户近期写作风格怎么获取，怎么防止把偶然噪声学成长期偏好？

写作风格不能靠最近几句话直接拟合，否则模型容易把用户一时的情绪、模仿或特定场景文风当成长期偏好。更合理的做法是从一段时间内的真实输出中抽取稳定特征，例如句长分布、敬语强度、列表偏好、开头结尾模板、词汇正式度和常用修辞，再和任务类型绑定——风格最好建成"用户 × 场景"的条件分布，而不是一个全局固定人格。更新时还要做衰减和置信度控制，避免短期异常样本污染长期画像。

12. 设计一个 Agent，怎么判断它是真的"好"，而不是只是会演示？

（答案未被截图覆盖）

13.（整题未被截图覆盖）

14. skill 是什么，为什么它不等于普通 function call？

skill 更像一个具备语义边界、输入输出规范、适用场景和调用前提的能力单元，而不只是一个裸函数。function call 只是执行接口，skill 还包含"什么时候该用、用了之后怎么解释结果、失败了怎么回退"的行为语义。把能力抽象成 skill 的好处是主 Agent 可以在更高层做决策，不必直接理解底层 API 细节；也正因此，skill 的设计质量会直接影响路由稳定性。

15. 大模型怎么识别当前应该调用哪个 skill，为什么 embedding 检索不够？

只靠 embedding 检索做 skill 选择，容易把语义相近但执行条件不同的能力混在一起。更稳的做法是三段式：先粗召回（可以用 embedding），再约束过滤（权限、上下文状态、参数是否齐全、设备环境是否满足），最后判别排序（结合当前任务目标、历史成功率和预期成本）。skill 选择其实是一个受状态约束的决策问题，不是纯语义匹配问题。

16. skill 的渐进式披露是什么意思，为什么它能提升 Agent 的稳定性？

渐进式披露就是不要一开始把所有工具和能力一次性暴露给模型，而是根据当前任务阶段、权限和上下文逐步开放。好处很直接：减少候选空间、降低误调工具概率、缩短 prompt、避免模型在无关能力上分散注意力。复杂业务里工具越多，路由混乱和越权调用的风险越大。渐进式披露本质上是在给模型做"受控视野"。

17. OpenClaw 这类框架如果真正拿来做生产级 Agent，最先要补的是什么？

最先要补的通常不是模型，而是运行时控制面：状态持久化、步骤级回放、失败恢复、工具幂等、权限校验、队列和重试策略、以及评测和日志体系。很多开源框架在演示层很顺滑，但一进生产就暴露出"执行过程不可追""出错不能复现""任务中断无法恢复"这些问题。真正的差距不是能否跑起来，而是能否在出问题时把它救回来。

18. Vibe Coding 工具为什么最近会被拿来问，面试里应该怎么答？

被问到的本质不是考你会不会一句话生成代码，而是看你是否理解它对研发流程的影响。比较稳的回答：它适合作为探索式原型、脚手架生成、重复样板代码和测试用例补全的加速器，但不能替代严肃的软件工程流程，尤其是在状态复杂、边界条件多、安全要求高的 Agent 系统里。真正高质量的使用方式是把它当"放大器"，不是"决策者"。

19. 如果一个 Agent 要同时处理语音、文本和工具结果，状态机应该怎么设计才不容易乱？

状态机最怕把"输入类型"和"业务状态"混在一起。更稳的方式是把会话状态拆成感知态、任务态和执行态：感知态记录最新语音转写、说话人、视觉 OCR 或文本输入；任务态记录当前目标、槽位、依赖和待确认事项；执行态记录已经调用的工具、返回值、超时和重试路径。这样语音 partial update 不会直接把业务状态冲掉，工具失败也不会污染任务状态。