腾讯

面经合集

完整信息

14 条问法 · 12 道题

本篇目录

大家好,我是二哥呀。

如果你是一位愿意相信努力、相信过程、相信一步一个脚印、相信自己能在 AI 时代分一杯羹的人,那接下来这份硬核的面经,希望你能认真读一读。

(全文比较肝,保证大家能学到很多很多,系好安全带,我们粗粗发~)

content

01、LLM 和 Agent 之间的联系和区别

老王第一问是概念题。“讲一下 LLM 和 Agent 之间的联系和区别。”

“先说联系。Agent 的每一次决策都由 LLM 做出。”

“要不要调工具、调哪个、参数怎么填、任务算不算完成,全是模型在拿主意,Agent 框架本身不做判断。”

“区别在职责边界。LLM 是无状态的文本生成服务,一次调用进一段上下文、出一段文本,调用结束什么都不记得,也改变不了外部世界。”

“Agent 是围绕 LLM 搭起来的执行系统,补上了模型缺的三样东西:”

  • 工具:让模型的输出变成真实动作,读文件、执行命令、查网页
  • 循环:一次调用解决不了的任务,拆成多轮推理加行动,直到完成
  • 记忆:跨轮次、跨会话保存状态,让系统记得之前发生过什么

“一句话总结,LLM 负责想,Agent 负责想完了真去干。”

老王追问。“那网页版的对话助手算 Agent 吗?”

“看有没有 ReAct 循环。纯问答是单次调用,进去一段话出来一段话,不算;一旦它开始自己联网检索、自己跑代码、拿着中间结果继续往下推进,就已经是轻量级的 Agent 了。”

“判断标准不是产品形态,是有没有『决策、行动、观察结果、再决策』的闭合回路。至于 ReAct 具体怎么转,下一题正好展开。”

02、ReAct Agent 由哪几部分组成

老王点点头。“了解 ReAct Agent 吧?它由哪几部分组成?”

“ReAct 就是推理加行动(Reasoning + Acting)的循环。拿我自己写的 PaiCLI-Python 来说,拆开是五个部分,每个都能落到具体模块:”

  • 模型客户端:和 LLM 通信,流式接收文本、思考过程和工具调用请求
  • 工具注册表:所有可用工具的清单,每个工具带一份 JSON Schema 描述
  • 工具执行器:拿到模型的调用请求后真正干活的模块
  • 循环控制:决定继续还是退出,我设的最大轮数是 20
  • 上下文管理:每轮检查消息总量,接近预算就压缩
用户交给它一个问题,是如何完成的

老王追问了一句。“那用户交给它一个问题,整个流程是怎么走的?”

“先做两件准备工作,把匹配到的 Skill 候选清单注入上下文,再检查一遍消息总量要不要压缩。”

“然后进入循环。把消息历史和工具清单一起发给模型,模型流式返回,要么直接给文本回答,要么发起工具调用。”

“是后者的话,执行器把工具跑完,结果以 tool 消息追加回历史,再次调模型。模型看到工具结果继续决策,要么接着调,要么给出最终回答。”

“退出条件有两个。模型不再请求工具,正常结束;或者到达 20 轮上限,强制收尾。”

“执行上还有两个细节。一个是只读工具最多 4 个并发跑,写操作严格串行,防止互相覆盖;另一个是流式场景下工具调用的参数是分片到达的,要按序号把参数片段拼接完整,再解析成 JSON 交给执行器,拼早了就是半截 JSON,直接解析失败。”

03、设计一个 Agent 框架,会分哪些模块

老王往椅背上一靠。“如果从零设计一个 Agent 框架,会分哪些模块?”

“核心六层:”

  • 入口层:命令行和交互式会话,管参数解析和结果渲染
  • Agent 层:三种执行模式,ReAct 循环、计划执行、多 Agent 协作
  • 模型层:统一的 OpenAI 兼容客户端,管流式解析、token 用量和计费
  • 工具层:注册表加执行器,再加十七个内置工具
  • 记忆与上下文层:短期消息历史、长期记忆库、上下文压缩
  • 安全层:命令黑名单、路径守卫、高危操作人工确认、审计日志

“安全层容易被漏掉,单独说一句。Agent 是真的会执行命令的,黑名单里躺着的都是狠角色,sudo、rm -rf 这类命令直接拦截。”

“写文件和执行命令要么标了危险等级、要么强制人工确认,所有执行记录落审计日志。能力越大的系统,越要先想清楚怎么拦住它。”

模块之间如何交互

“启动时组装,入口层把内置工具和 MCP 工具合并注册进同一张工具注册表,交给 Agent。”

“运行时流转,Agent 持有消息历史,每轮把历史交给模型层,模型返回的调用请求交给工具层执行,结果回填历史,循环往复。”

“关键的设计决定是,所有模块对外只输出一种东西,统一格式的流式事件。文本增量、思考增量、工具调用、用量统计,都是事件,入口层只管渲染,不掺和逻辑。”

“好处是每层都能单独替换。换模型只动模型层,加工具只动注册表,改界面只动入口层。”

04、MCP 和 tool 之间有什么联系和区别

老王在本子上记了一笔。“MCP 和 tool 之间的联系和区别,说说看。”

“区别看归属。tool 是应用内的函数,我自己写、自己注册、跟着代码走,别的应用用不了。”

“MCP 把工具从应用里拆出来,变成独立的服务进程,任何支持 MCP 的客户端都能连上来用。解决的是 M 个应用对接 N 个工具的组合爆炸问题。”

“联系是殊途同归。MCP 工具连上来之后,会被包装成和内置工具一样的形态,注册进同一张工具注册表,最终以函数调用(Function Calling)的格式一起喂给模型。”

“模型不知道也不需要知道,一个工具到底是本地函数还是远端服务。”

“实现上我做了三件事:”

  • 传输支持 stdio 和 Streamable HTTP 两种
  • 远端工具名加服务名前缀做命名空间隔离,防止和内置工具撞名
  • 权限上参考远端声明的只读提示,非只读的 MCP 工具一律人工确认后才执行

“配置也是分层合并的。用户目录一份全局配置,项目目录一份局部配置,同名服务后者覆盖前者,路径里支持环境变量展开。”

“某个 server 连不上时单独隔离并记下错误,不影响其他工具正常注册。”

“还有个容易被忽略的点。MCP 除了工具还有资源和提示词模板,我把它们也映射成了虚拟工具,列资源、读资源和调用普通工具走的是同一条路径,模型侧不用学新动作。”

05、短期记忆和长期记忆是怎么做的

老王翻了页简历。“项目里的智能问答,短期记忆和长期记忆是怎么做的?”

“短期记忆就是会话内的消息历史,一个列表,上限 100 条,配合上下文压缩工作。”

“压缩的触发线是可用输入预算的 80%,一旦超过就压到 55%,最近 6 条消息原样保留,更早的轮次做提取式摘要。分割边界落在用户消息上,保证工具调用和结果成对出现。”

“长期记忆用 SQLite 存在用户目录下,跨会话生效,按项目路径隔离作用域。有几个设计细节可以展开:”

  • 去重:内容归一化后取哈希,同作用域下相同哈希只存一条
  • 淘汰:上限 1000 条,超了按重要性、置信度、访问次数从低到高淘汰
  • 过期:支持 TTL,临时事实到期自动失效
  • 召回:词法匹配为主,叠加重要性、新鲜度、访问频次加权,默认召回 6 条,低于分数阈值的不进上下文

“还有一条边界要守住。压缩生成的摘要只服务当前会话,它是模型生成的二手信息,不会被晋升成长期记忆。”

“长期记忆只收用户明确要求保存的事实。这条线一旦松了,记忆库很快会被模型自己的转述污染。”

业界主流的三层记忆系统

老王接着追问。“业界主流的三层记忆系统是怎么分的?每层存什么?”

“主流分法是按作用域切三层:”

层次 存什么 在 PaiCLI-Python 里
会话层 当前对话的消息 内存里的消息列表,上限 100 条
项目层 仓库的规范、构建命令 项目根的 PAI.md,跟着 Git 走
全局层 跨项目的个人偏好 用户目录的记忆库和全局配置

“文件记忆还有一个本地覆盖层 PAI.local.md,存只属于本机的配置,不进版本库。加载也有预算,单文件截断 6000 字符,合并总量 16000 字符,防止记忆把窗口吃穷。”

这张表建议存下来,答记忆类的题基本都能套。

06、Skill 的渐进式加载机制了解吗

老王抛出下一问。“了解 Skill 的渐进式披露(progressive disclosure)机制吗?”

“了解,核心就八个字,索引常驻,正文按需。具体分两段。”

“第一段,每次用户输入时,只把匹配度最高的 5 个 Skill 的名字和描述注入上下文,单条描述截断到 300 字符,整个索引不超过 4000 字符。这时模型知道有哪些技能可用,但一个字的正文都没进来。”

“第二段,模型判断当前任务匹配某个 Skill,主动调用加载工具,这时才读 SKILL.md 的正文,上限 5000 字符。而且正文不是立刻塞进当前轮,是放进一个缓冲区,下一轮随工具结果一起注入,缓冲区只保留最近 3 条,防止越积越多。”

“Skill 目录本身也分三层,内置的、用户级的、项目级的,同名时项目级覆盖用户级,和记忆文件的分层逻辑一致。”

“这套机制的收益可以量化。20 个 Skill 按单篇 5000 字符的上限全量加载,就是 10 万字符;渐进式披露的常驻成本只有 4000 字符的索引,差 25 倍。”

老王追问。“候选是怎么匹配出来的?”

“加权打分。用户显式点名某个 Skill 直接给最高分;否则按命中位置算,名字命中的权重最高,标签次之,描述最低,中文还做了二元、三元分词来提升召回。”

“说白了就是一个微型搜索引擎,检索对象从网页换成了技能。”

07、使用 AI 时,如何保证输出内容的质量

老王问出最后一道正题。“在使用 AI 时,应该怎么保证输出内容的质量?”

“分三层答,先说我实现了的。”

  • 写后自检:写入或修改 Python 文件后立即做语法编译检查,报错附在工具结果里回给模型,让它当轮就改
  • 审查重试:多 Agent 模式里有专职的审查者角色,产出不合格打回重做,每步最多重试 2 次
  • 安全兜底:危险命令黑名单、路径守卫、高危操作人工确认、全程审计日志,外加任务前后各打一次快照,随时可回滚

老王追问。“这些都是工程手段,提示词层面呢?”

“三条实践。把验收标准直接写进提示词,让模型知道什么叫合格;复杂任务要求模型先复述一遍理解再动手,提前暴露偏差;重要产出让模型对照标准自查一轮再交付。”

“也坦白说,通用的钩子机制和结构化输出校验我还没做,主循环也没有自动重试。这道题面试时最忌讳把没做的说成做了——质量保证的第一条,是先保证自己说的话是真的。”

老王笑了笑,合上了本子。

PaiCLI 如何写到简历上?

项目名称:PaiCLI-Python

项目简介:对标 Claude Code 的 Python Agent 命令行工具,支持 ReAct、计划执行、多 Agent 三种模式

技术栈:Python、asyncio、httpx、MCP、SQLite

核心职责:

  • 基于函数调用实现 ReAct 主循环,流式拼接工具调用参数分片,只读工具 4 路并发执行,20 轮硬上限防失控
  • 设计三层记忆体系:会话内消息历史、用户级与项目级分层文件记忆、SQLite 长期记忆,支持哈希去重、TTL 过期与 1000 条容量淘汰
  • 实现窗口自适应的上下文压缩,预算 80% 触发压至 55%,分割边界落在用户消息上,保证工具调用与结果成对完整
  • 接入 MCP 官方 SDK,支持 stdio 与 Streamable HTTP 双传输,服务级配置分层合并与故障隔离,远端工具统一命名空间注册
  • 实现 Skill 渐进式披露机制,索引常驻 4000 字符、正文按需加载,常驻上下文成本降低 25 倍

反问

08、结合面试表现,后端和 Agent 方面怎么学

面试收尾,轮到我反问。“结合我刚才的表现,后端和 Agent 方面能给点学习建议吗?”

老王想了想,给出的建议信息量很大,太用心了兄弟,我都想给他鞠个躬。原话拆开,是一份完整的自查清单:

  • 模型怎么运转:ReAct 主流框架下,模型和框架各自负责什么,边界在哪
  • 模型的缓存机制:前缀缓存命中和未命中的成本差,怎么组织上下文去吃这个红利
  • 怎么让输出更稳定:温度参数、结构化提示、约束性描述
  • Skill 的运转逻辑:索引注入和按需加载的两段式,预算怎么定
  • MCP 和 tool use 的机制:协议、传输方式、命名空间、权限控制
  • 上下文管理:压缩触发线、保留策略、消息边界完整性
  • 参考实现:Claude Code 的开源生态里,上面这些机制都能找到对照
  • RAG 的知识管理和召回:切块策略、混合检索、重排序,怎么让召回更准更精

这份清单每一项,都能对着一个真实项目的源码过一遍。

ending

以前后端面试拼的是并发和中间件,现在拼的是懂模型、懂工具调用、懂记忆、懂上下文。

我们有机会站在 AI 发展的风口浪尖,把 Agent 从名词表变成自己简历上扛得住追问的项目。虽然挑战不少,但也充满了无限可能。

加油吧,兄弟姐妹们。

下期见。

原帖题单截图可见文字

  • 请讲一下LLM和agent之间的联系和区别吗?
  • 了解react agent吗?react agent由哪几部分组成?它的执行流程是怎么样的?比如用户交给他一个问题是如何完成的?
  • 如果让你设计一个agent框架,大概会分为哪些模块呢?他们之间如何进行交互呢?
  • MCP和tool之间有什么联系和区别?
  • 你的ai项目里的智能问答知识库的短期记忆和长期记忆是怎么做的?业界的主流的3层记忆系统是怎么样的?每一层分别存了什么东西?
  • 了解skill的“渐进式加载(渐进式披露)”机制吗?
  • 在使用ai时,应该如何保证输出内容的质量?
  • 反问:你对于我在后端还有agent方面学习的一些建议结合我刚刚的面试表现?

截图底部另一条文字被裁切,只能看到“react 主流的框架,你得知道模型是如何”,未据此补写后文。

原帖解答配图中的实现说明

  • “LLM 与 Agent 的边界”图写 Agent = LLM + 工具 + 循环 + 记忆。
  • “ReAct 的五个组成部分”图列模型客户端、注册表、执行器、循环控制和上下文,目录分别为 core/、tools/、runtime/、loop/、context/。
  • “一次请求的完整流转”图为用户提交请求、模型读取历史并判断、发出工具调用、执行器执行并返回、结果作为 tool 消息写回、模型再次判断。图中设 20 轮上限。
  • “框架的六层划分”与事件流图列入口层、Agent 层、模型层、工具层、记忆层、安全层,各层向全链路流式事件总线上报,供观测、追踪和告警。
  • “MCP 工具的接入路径”图列 stdio 与 Streamable HTTP,经 MCP 适配器完成协议适配、鉴权校验、消息转换、工具标准化。来源前缀 ns_a/、ns_b/ 用于命名空间隔离,统一注册表保存描述、输入输出、权限、来源、版本。
  • “长期记忆的治理机制”图列哈希去重、1000 条上限、TTL、相关度和时间加权召回。该图容量项写“超过容量淘汰旧项”“先进先出(FIFO)”。
  • “三层记忆系统对照表”图列全局层保存跨项目偏好与通用记忆、项目层在 PAI.md 保存项目规则与长期上下文、会话层在消息历史中保存当前对话与临时状态。
  • “渐进式披露的两段加载”图为索引注入 4000 字符,命中后按需加载正文 5000 字符,缓冲区 3 条,先看索引再取正文。
  • “输出质量的三层保障”图列写后自检、审查重试、安全兜底,并写“快照回滚:未实现”“依赖系统快照,发生异常时回滚(规划中)”。
  • “Agent 学习自查清单”图列模型运转、缓存机制、输出稳定、Skill 机制、MCP 与工具、上下文管理、源码实践、RAG 召回。
本篇目录
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
  9. 09
    追问
    老王接着追问。“业界主流的三层记忆系统是怎么分的?每层存什么?”
  10. 10
    老王抛出下一问。“了解 Skill 的渐进式披露(progressive disclosure)机制吗?”
  11. 11
  12. 12
  13. 13
  14. 14
    反问
    面试收尾,轮到我反问。“结合我刚才的表现,后端和 Agent 方面能给点学习建议吗?”

相关公司