Agent面经记录

目录

2026/8/1

自己虽然实操了各种ai的知识，但是现在还不了解面试的问题，所以记录一些自己在牛客看到的，但是不知道的内容

2026/8/17

今天开始正式投递，自己慢慢的积累面经知识吧

ReAct 和 Agent Loop 都是循环，本质区别在哪里？

os：ReAct我知道，我也在用，但是agent loop是啥？

RAG 单轮和多轮推理的核心差别在哪里？

os：RAG还能推理呢？检索返回相关文档，哪一步要推理？不懂

项目中挑战最大的是什么？（答了微调，面试官说没听懂产出，又解释了一遍，应该也没明白，跳过）

os：微调？这东西不应该属于模型范畴吗，据我了解微调好像是修改模型本身呀，这个我看面经里是个人都会，是我菜了吗？

如果遇到api超时和报错怎么解决？（答根据重要程度处理）

os：这个超时和报错属于维护方面了，暂时还没考虑到，一般设计都应该有对应的兜底策略，因为超时和报错属于常见的错误场景，如果要上线使用，这是基本应该考虑到的

消耗token过快怎么排查

os：这个也还真没考虑过，注意力都在知识的了解上，暂时还没考虑成本问题

这是一份牛客的答案，不过我没看懂：

token消耗相关的问题应该是做可观测相关的接入吧，就像Eino Callback可以生成一颗LLM span的树，有一个OnEndWithStreamOutput的hook，这样就可以drain输出流的一份独立拷贝，从末帧就可以读到四类token用量了，当然也可以用mq简单对token做一个异步落库的处理在日志内排查 ...

作者：offer来

链接：https://www.nowcoder.com/feed/main/detail/3e22dc2df03d4227ab70ea9c2d896086?sourceSSR=search

多智能体协作方面，有没有具体做过多智能体，哪个项目用到了

os：多智能体？写个函数叫made_agent 然后创建两个实例，把一个智能体包装成工具打包进另一个智能体的工具栏中，这就实现多智能体了吗，至少我之前是这么干的

你说说RAG和Fine-tuning分别适合什么场景

首先fine-tuning是微调的意思，其实就是再问RAG和微调的使用场景是什么，他们两个的公共特点都是为了让模型具备更加专业化的知识，以回答更加专业的问题 ，而非通识问题，而二者的区别在于训练成本和内外部调用，

因为微调的训练成本高，其本质是为了让模型本身通过大量数据学习总结的训练模型，需要调节各种参数，具备耗时，耗材的缺点，所以一般会将一些专业术语或者某种风格的训练采用微调的方式，

而RAG创建成本低，其实现原理是通过外部向量数据库实现语义检索，得到专业知识数据内容，结合内容生成答案，它的有点就是成本低，所以适合动态多变的实时数据

追问：“在知识库更新频繁，你会选哪一个，为什么”

很明显会选RAG，因为更新频繁，对于RAG来讲只不过是刚更新一下数据库，而对于微调来讲，那就是一次新的模型训练，成本差距较大，所以会选RAG

【补充】微调的耗时耗材可以改成，算力和数据标注成本高，迭代周期长

Agent 的ReAct框架你了解吗，跟普通的Chain有什么区别？

首先，ReAct其实就是一个较为复杂的Chain，其核心设计为三个节点，一个thougt节点，用来判断当前完成内容是否需要做出哪些行为，action节点负责实现这些工具调用，observation节点负责查看当前返回的数据是否足够完成任务，否则继续发出调用指令，循环到action节点，直至数据内容足以回答问题。

跟普通chain的区别，最大的地方就是前者是循环，后者是单调，前者会根据当前数据是否完善采取多轮调用，后者只会完成一次，比较上来说，前者更容易完成复杂的任务，且结果更加完善。

追问“那你们的Agent会幻觉吗，怎么处理的”

首先在我的项目中，如何判断agent是否产生幻觉，是通过ragas的忠诚度去判断，低于0.7的指标，常规指标在0.85，这是一个硬性的指标，还可以通过提示词的方式去一直幻觉，比如在提示词中写请严格根据下面的文档回答内容，若文档不足以回答，则返回内容不足，另一个方式就是增加RAG系统，使得agent具备检索私有知识库的能力，这样他就会检索到相关准确内容，不会凭空捏造

【补充】react本质是推理与行动交替，以环境反馈驱动下一步，落地的实现可以是三点也可以是一个agent一个tool一个条件边

在多agent系统中，你是如何设计任务分配的

首先是一个意图识别节点，人工识别+llm兜底，判断出当前的问题应该是简易回答，还是RAG检索，还是多agent调用，在多agent调用中，会考虑问题是否可以实现并行解决，还是串行解决，如果是并行解决，可采用多agent方式，具体的任务分配由提示词赋予能力

追问：“那agent之间是如何通信的，公共内存还是消息队列”

这个需要看应用场景，如果是在同一个langgraph里面，传递消息的方式是通过state状态去实现，也就是公共内存，那消息队列的应用场景是，异步进行，后台进行，需要占用主进程的时间，

【补充】设计任务分解agent和多个子任务agent，中间通过langgraph的条件边实现路由，最后通过共享状态state实现信息汇总，如果是都写在一个langgraph中，可以使用state共享状态，如果为了解耦，异步进行，就选择消息队列。

Agent 上下文窗口不够用怎么办

常规的方法是滑动窗口和摘要压缩，我们首先可以通过窗口的token数限制判断 是否需要压缩或者滑动，滑动窗口的实现原理就是保留最近的几十条内容，去除之前的部分，而压缩则是他通过调用llm对已有的内容进行初步压缩，以达到减少token的效果，据我了解了解到的其他方式，可以将上下内容存入数据，然后还可以利用知识图谱实现长期记忆，

追问“那摘要本身也要消耗token，你怎么控制这个开销”

如果教我设计的话，首先我对限制生成token数，然后通过手动识别的方式，判断生成的答案是完整答案还是因token数截取的答案，具体的实现方式是一个是通过语义，标点符号结束来判断，一个是json格式的括号是否匹配来判读，如果是完整答案就是返回使用压缩策略，否则就用滑动窗口采取兜底策略。

【补充】摘要不做全量摘要，而是做增量摘要

简单介绍一个你比较熟悉的Agent项目，包括业务背景、整体架构设计以及你主要负责的工作内容

优先选择wikfoge ，业务背景就从rag的基本功能实现，以及一些其他优化部分说，比如人工审核通道，部分员工权限查询限制，整体架构设计从选择的技术栈开始说，数据库用qdrant opensearch 主要负责的内容就可以从简历上个的几点开始说起，三路找回的设计，查询问题三种预处理方法，以及模型调用限时处理和重试处理，以及重排序兜底策略等等

补充：还设计了基于ABAC的权限设计模型，具体实行是在PG数据库设计权限表，具体列包括用户id，文档id，文档类型，权限类型，存入用户权限之后同步更新Qdrant数据库相关chunk的元数据信息，具体而言就是元数据一栏会有一个允许查询用户id列表，对此元数据进行更新，同时为了确保查询效率，通过 redis 缓存用户与文章的权限，这样查询会更加迅速

ai二次补充：

  • 三路召回优化：三路并发执行，每路3秒超时，超时那路直接跳过不堵塞，召回结果用RRF，k=60融合排序，而不是简单的拼接

  • ABAC权限设计强调继承****和覆盖机制：文档级权限会优先于空间级权限，其次权限在Qdrant迭代失败之后会连同PG数据一同回滚

  • 人工审核要说触发条件：不是所有人都审，而是通过多维度打分，总分低于0.7的自动进入审核队列，

  • 补充文档处理管线celery全流程，上传异步管线，实现从文档解析，profile匹配，数据清理，切块，向量化，存入数据库全过程，并且每步实时写入redis，前端轮询进入，同步后端文档上传进程

  • 为什么选择这些技术栈：

    • Qdrant：稀疏稠密两种向量检索方式，提高召回效率，其次自带Pre-filtering 前置过滤功能，即先进行元数据提出，然后进行向量检索

    • Opensearch：全文检索BM25+IK分词，对中文分词效果好

  • 模型调用限时要说清分层：

    • 查询增强层：改写2s HyDE 3s 分解2s 整体5秒超时-降级用原查询

    • RAG流式层：首token 30s ，整体LLM调用60s

    • Celery 任务层：指数退避重试，10s-20s-40s 最大三次

缺少"旁路短超时、主链路长超时"的分层理念

LLM 客户端无复用，属低级浪费

MCP 服务器挂掉 = 整个 Planner 崩溃落入默认计划，而不是"降级为只用本地工具继续"

posted @ 2026-08-26 18:44  zxsoul  阅读(33)  评论(0)    收藏  举报