Momenta AI Agent开发 二面

1、自我介绍

2、项目介绍

3、Agent 的核心组成是什么

LLM Agent 本质上不是单独一个大模型,而是由模型、提示策略、工具、知识、记忆和执行接口组成的系统。可以概括成:

[Agent = LLM + Prompt + Tools + Knowledge + Memory + Interface]

其中 LLM 负责理解和生成,Prompt 决定任务边界和行为方式,Tools 负责访问外部能力,比如检索、地图、计算、数据库和 API,Knowledge 负责补充外部知识,Memory 负责保留短期上下文和长期用户信息,Interface 则负责把 Agent 和外部系统连起来。

如果任务比较简单,Agent 可能表现为单步工具调用;如果任务复杂,就会演化成带状态的工作流系统,支持规划、执行、观察、反思和重试。真正能在线上稳定运行的 Agent,一定不是“模型自己想怎么干就怎么干”,而是模型负责理解和决策,系统负责约束、记录、恢复和兜底。

4、上下文工程是什么,和 Prompt Engineering 有什么区别

Prompt Engineering 更强调“提示词怎么写”,重点在于任务描述、角色设定、输出格式、few-shot 示例和约束表达。上下文工程的范围更大,它关注的是模型最终看到的整份输入是如何构成的,包括系统提示词、用户输入、历史对话、检索结果、记忆、工具返回、中间状态以及这些内容的顺序和裁剪方式。

在 Agent 场景里,很多效果问题并不是 Prompt 本身差,而是上下文组织出了问题。比如:

  • 检索片段太多,关键信息被淹没
  • 对话历史太长,旧信息干扰当前任务
  • 工具返回内容太原始,模型难以使用
  • 不同来源上下文相互冲突
  • 状态信息没有显式告诉模型,导致步骤混乱

所以 Prompt Engineering 更像局部表达优化,上下文工程更像输入全局设计。真正稳定的系统,通常不是只改几句提示词,而是同时优化“给模型什么信息、按什么顺序给、保留多少历史、如何压缩中间状态”。

5、幻觉产生的原因是什么,怎么解决

幻觉本质上是模型在缺乏足够依据时,生成了看起来合理但不真实、不准确或者不可验证的内容。原因通常有几类。第一类是参数记忆本身不可靠,模型只是在做概率生成,不是真正的事实检索。第二类是上下文不足或者上下文冲突,模型没有足够证据却仍然被要求回答。第三类是检索链路有问题,召回内容不准或者排序不合理。第四类是工具调用结果没有被严格约束,模型对返回内容做了自由发挥。第五类是输出目标过于开放,缺少结构化约束和拒答策略。

解决思路一般也是系统性的。先提高外部证据质量,比如 RAG 的召回、重排和上下文组织;再通过 Prompt 明确要求“无依据不回答”;再通过结构化输出把结论和依据拆开;对高风险任务再加校验层,比如检查回答中的关键事实能否在证据中找到支撑。对于 Agent,工具返回的关键字段最好直接引用,不让模型自己改写,比如数值、经纬度、时间、状态码这些内容都应该受控。

真正的目标不是让模型永远不犯错,而是让它在不确定的时候少编、敢拒答、回答可追溯。

6、RAG 里面上下文怎么组织才更有效

RAG 不是把 topk 文档直接拼进去就结束了。上下文组织通常决定了最终回答质量。常见做法是先做 query rewrite,把用户口语化、模糊化的问题改造成更适合检索的查询;然后做多路召回,比如向量检索、关键词检索和规则召回结合;接着做 rerank,把最相关片段放前面;最后再做上下文压缩和结构化组装。

组织上下文时我一般会注意这几件事。第一,片段要保留来源和标题,防止模型失去语义边界。第二,重复片段要去重,不要浪费 token。第三,冲突证据要显式保留出处,避免模型自动混合。第四,片段顺序很重要,一般会把最高相关、最完整、最直接回答问题的内容放前面。第五,如果工具返回和检索结果同时存在,要区分“可信结构化结果”和“补充文本证据”。

对于长上下文,不能一味堆内容,很多时候更有效的是先做压缩摘要,再把摘要和关键原文片段一起给模型。

7、LangGraph 和 LangChain 的区别,状态快照机制是什么

LangChain 更偏组件化封装,适合把模型、Prompt、检索器、工具这些能力串成链,适合线性流程或者相对简单的问答应用。LangGraph 更偏图式执行和状态流转,更适合复杂 Agent,比如多步规划、循环执行、分支判断、失败回退和人工介入。

状态快照机制本质上是把 Agent 在某个时刻的完整执行状态保存下来。它不只是保存聊天记录,还应该包括:

  • 当前 session_id 和 task_id
  • 当前执行节点
  • 历史消息
  • 中间变量
  • 工具调用记录
  • 工具返回结果
  • 错误信息
  • 重试次数
  • 时间戳
  • 版本号

有了快照以后,任务失败时可以从中间步骤恢复,而不是每次都从头执行。它还可以用于回放调试、线上审计和错误复现。对于复杂 Agent,状态快照不是可选项,而是基础能力。

8、Agent 里的记忆怎么设计

记忆一般分成短期记忆和长期记忆。短期记忆服务当前任务,主要保存最近几轮对话、当前目标、中间步骤、工具返回和未完成动作;长期记忆保存稳定事实,比如用户偏好、历史配置、常用路线、任务经验和个性化信息。

设计时不能简单把所有对话都塞进去,否则上下文会越来越臃肿,而且噪声会越来越多。比较合理的做法是:

  • 最近几轮对话直接保留
  • 长对话定期摘要压缩
  • 从摘要中提取稳定事实写入长期记忆
  • 检索时先查短期记忆,再补长期相关记忆
  • 对低价值、重复、过期信息降权或删除

如果做本地或者轻量级部署,常见组合是 SQLite + FAISS。SQLite 存结构化元数据,FAISS 存 embedding 向量。这样既能做精确过滤

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

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

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

全部评论

相关推荐

本人技术栈主要是Python+Go,之前有两段后端实习经历一面一开始面试官就围着我之前的实习项目问,问得还挺细的:当时做项目的时候,为什么要引入父子索引?还有BM25,引入的原因是什么,比例是怎么设置的,整个具体流程是怎样的,有没有做rerank操作?如果做了rerank, rerank之后返回几个块?有没有做过一些验证来确保效果?rerank之后的topk截断是怎么实现的?为什么选这个k值,有没有考虑过其他方案?让我讲一下上下文工程,还有记忆功能是怎么实现的。除了AI相关的项目,还问了我之前做的后端实习项目,都是一些项目里的细节问题。分布式令牌桶限流、漏桶限流,还有滑动窗口算法限流,这三个都让我讲一下。尤其问了滑动窗口的数据结构会包含哪些字段,滑动窗口对比令牌桶有什么缺点,还有用Redis的什么数据结构能实现滑动窗口。又绕回我自己做的项目,让我讲一下LRU的原理和实现。布隆过滤器的原理、应用场景,也让我详细说一下。MySQL索引失效的情况,这块我八股好久没看了,只想起来两个,被面试官追问了好久,有点没答好。面试官还补问了一句,like查询会不会导致索引失效。MySQL的事务隔离级别,还有一致性相关的内容,让我讲清楚。MVCC这块问得特别细,反复追问,还举了具体场景,问这种情况下会创建几个readview,我当时琢磨了半天,尽量把自己知道的都讲了。最后还问了MySQL的锁相关知识,行锁、表锁这些都涉及到了。手撕代码环节,我跟面试官坦诚说,最近一直在实习,好久没刷过题了,然后面试官就出了一道反转链表,不算特别难,慢慢理清楚思路就做出来了。二面跟一面不一样,二面全程没涉及后端相关的问题,全是AI agent和RAG相关的,而且大部分都围绕我之前做的RAG项目展开,问得特别深入。首先问我,做RAG项目的时候,是怎么评测效果的?有哪些评测维度,具体用到了哪些指标?然后问项目里的数据集包含什么内容,数据来源、数据格式这些都问到了。如果让我对RAG的相关度和回答效果做优化,我有什么思路?有没有更体系化的优化方案,而不是零散的调整。面试官还举了个具体场景,比如有一千条数据,需要做求和处理,让我说说这种数据处理场景,我会怎么设计实现。RAG的性能怎么提升,有没有实际的优化思路,不管是工程层面还是算法层面。我项目里的上下文是怎么处理的,有没有什么优化的方向,比如上下文过长、冗余这些问题怎么解决。agent的长记忆和短记忆之间,怎么做到协同工作的,两者的衔接逻辑是什么。最后问我,有什么思路能让自己做的agent更智能?这个问题我感觉太宽泛了,当时没太get到面试官具体想了解什么,就主要围绕我工程开发中遇到的实际问题,讲了一些针对性的优化思路。手撕代码环节,出的是全排列,这个之前刷过类似的,思路比较清晰,顺利做出来了。感觉面试官比较爱问的AI问题就是RAG 的全链路优化、Agent、减少幻觉
查看23道真题和解析
点赞 评论 收藏
分享
评论
4
22
分享

创作者周榜

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