联想 agent应用开发 一面(暑期)

1. 自我介绍

自我介绍不要按时间线念简历,直接围绕岗位能力说。可以先用一句话说明自己主要做 Agent 应用、语音交互链路、工具调用编排和推理服务,然后挑两段最能体现深度的经历展开:一段讲系统设计,比如多 Agent 协作、上下文压缩、工具协议和评测闭环;另一段讲落地,比如低延迟 ASR 接入、意图识别、写作风格学习、线上指标和 bad case 修复。最后收在一个最近做得最深的点上,例如流式语音 Agent、MCP 工具治理、skill 路由或者多约束任务规划,让后面的追问自然落到自己准备过的区域。

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

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

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

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

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

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

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

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

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

主 Agent 的意图识别不能只做一个句子级分类器,因为真实对话里的意图往往依赖历史状态、未完成任务、工具返回和用户角色。更稳的方式是把意图识别建成一个带状态的判别过程:先抽取当前显式动作,再结合历史任务栈、未决槽位和最新环境事件决定用户此刻是在追问、纠错、切换任务、补参数还是启动新流程。单轮分类器经常不够用,是因为它看不到“用户上一轮已经让你查过一次”这种上下文依赖。

7. 主 Agent 和子 Agent 的模型该怎么分配,为什么不一定都用同一个大模型

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

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

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

from collections import defaultdict, deque

def topo_sort(tasks, deps):
    g = defaultdict(list)
    indeg = {t: 0 for t in tasks}
    for a, b in deps:
        g[a].append(b)
        indeg[b] += 1
    q = deque([t for t in tasks if indeg[t] == 0])
    order = []
    while q:
        x = q.popleft()
        order.append(x)
        for y in g[x]:
            indeg[y] -= 1
            if indeg[y] == 0:
                q.append(y)
    return order if len(order) == len(tasks) else None

tasks = ["总结会议", "抽取行动项", "生成跟进邮件"]
deps = [("总结会议", "抽取行动项"), ("抽取行动项", "生成跟进邮件")]
print(topo_sort(tasks, deps))

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

只看任务成功率会掩盖太多问题。真正可用的评测至少要把路由正

剩余60%内容,订阅专栏后可继续查看/也可单篇购买

AI-Agent面试实战专栏 文章被收录于专栏

本专栏聚焦 AI-Agent 面试高频考点,内容来自真实面试与项目实践。系统覆盖大模型基础、Prompt工程、RAG、Agent架构、工具调用、多Agent协作、记忆机制、评测、安全与部署优化等核心模块。以“原理+场景+实战”为主线,提供高频题解析、标准答题思路与工程落地方法,帮助你高效查漏补缺.

全部评论

相关推荐

【最煎熬的一段时期】阶段: 等待OC经历:目前正在经历的时间,有家风评不太好的公司发了offer,薪资差强人意只能给统一的打包价,上周面完二面就是第二天就是HR和我沟通offer,还有待遇情况,说现在就可以走审批流程,走完之后发了offer给我七天考虑时间选择接受还是不接受当时心态:一半是终于抓到救命稻草的释然,一半是不甘心将就的纠结,两种情绪天天在心里打架。春招拖到现在,简历投出去大多石沉大海,偶尔的面试要么是外包,要么是初创公司画大饼,这家公司虽然风评一般,但至少是个正经的 Java 后端岗,不用被迫转去做游戏 C++ 或者c#做工业软件,就是需要出差和驻场。HR 沟通待遇的时候,我听到那个统一打包价,心里咯噔一下 —— 比我的期望薪资低了一截,而且年终奖还和公司业绩挂钩,没个准数。但 HR 说审批流程很快,offer 一周内就能发,那一刻我还是忍不住松了口气,至少不是完全没着落了。可冷静下来之后,各种顾虑又冒了出来。刷牛客网的时候,看到不少人吐槽这家公司加班严重,而且晋升机制模糊,应届生进去就是干杂活,学不到核心技术,而且还需要出差跟着项目走,驻场开发。每天早上醒来第一件事就是看邮箱,既盼着 offer 快点发过来,又怕真的收到了,要做那个 “接受还是拒绝” 的决定。更不敢跟家里人说这些纠结,每次打电话都只说 “有个公司在走流程了,挺好的”,挂了电话就对着招聘软件发呆。有时候会忍不住想,要是当初秋招的时候更努力一点,要是春招前期面那些好公司的时候,再准备充分一点,是不是就不用现在这么煎熬?现在每天还是会抽时间投简历、刷算法题,抱着一丝侥幸心理,盼着能有更好的机会出现。但又怕拖着不签这份 offer,最后落得竹篮打水一场空。这种悬在半空的感觉,比没收到任何面试通知的时候,还要磨人。
从投递到OC,你用了多久
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务