公司未注明

面经合集

完整信息

16 条问法 · 13 道题

本篇目录

内容来自个人+收集自互联网公开的佬们分享的个人面经整合~内容持续更新汇总(偏向于口述版)

1.你对 Agent 了解多少呢?

Agent(智能体)是一种能够感知环境、自主决策、执行行动的 AI 系统。与传统的"一问一答"式 LLM 调用不同,Agent 具备以下核心能力:

本质定义:Agent = LLM(大脑) + 感知(Perception) + 记忆(Memory) + 规划(Planning) + 工具使用(Tool Use) + 行动(Action)。Agent 以目标为导向,可以在无人干预的情况下,自主拆解任务、选择工具、执行操作、观察结果并迭代优化,直到任务完成。

学术渊源:Agent 的概念最早可追溯到人工智能的 BDI(Belief-Desire-Intention)架构。2023 年以来,随着 GPT-4 等大模型能力的提升,基于 LLM 的 Agent 成为热门研究方向。标志性工作包括 AutoGPT(2023)、BabyAGI(2023)、ReAct 论文(Yao et al., 2022)以及 Generative Agents(斯坦福小镇,2023)。

产业现状:根据 LangChain 2025 年底的调研,超过 57% 的组织已有 Agent 在生产环境中运行。Gartner 预测,到 2028 年 33% 的企业软件将嵌入 Agentic AI 能力。这个领域正从"能不能做"转向"如何规模化、可靠地部署"。

大厂面试追问角度:面试官可能追问"你在实际项目中如何落地 Agent",回答要点:选择合适的框架(如 LangGraph)、设计稳健的 Agent Loop、关注 Error Recovery、成本控制和可观测性。

2. Agent和LLM(大型语言模型)有什么区别?

参考口述答案:

可以这样理解:LLM 是个大脑,Agent 是个完整的人。

LLM 就是纯语言模型,你问它答,它没有手脚,不能自动去查东西、不能用工具,也不知道什么时候该去查东西。

Agent 是把这个大脑放在一个“身体”里,给它配上记忆、规划、工具,让它可以主动感知环境、做决策、执行动作,并且根据结果再调整。

举个例子,你让LLM帮你订酒店,它只能告诉你“你可以去某某网站订”。

但Agent收到这个指令,会自己打开网页、搜索酒店、比价、填表、点击预订,在这个过程中如果报错,它还会自己看看问题再修正。

所以简单说:LLM 提供语言和推理能力,Agent 提供的是把这种能力变成真正任务闭环的一套系统。

3. 一个完整的Agent智能体架构一般包括哪些部分?

参考口述答案:

我觉得主流的划分,基本都绕不开四大核心模块:

  • 大脑 / 推理核心:一般就是一个LLM,用来理解任务、做拆解和推理。
  • 规划模块:负责把大任务拆成小步骤,像CoT、思维树、任务分解这些都在这个层面。
  • 记忆模块:分两块,短期记忆比如当前对话上下文,长期记忆一般用向量数据库存历史经验和知识。
  • 工具使用模块:让 Agent 能调用搜索引擎、计算器、代码解释器、各种API等,真正去干活。

如果画一个图,大概就是:

用户输入 → 规划(拆任务) → 回忆相关记忆 → 调用工具 → 得到结果 → 总结输出 → 必要时再回到规划循环。

有一些架构还会加一个反思/自我批评模块,就是在行动后检查自己有没有做错,要不要重来。这也是现在提高成功率很重要的点。

4. Agent的工作模式都有什么?

参考口述答案:

常见的主要是三种工作模式,复杂度由低到高:

  1. 单步执行模式:收到指令,一次性推理完直接出结果,不做多轮交互,本质上更像“聪明一点的LLM调用”。
  2. ReAct 模式:也就是 推理–行动–观察 的循环。Agent 会一边想一边做,每次做完看看结果,再决定下一步怎么走。这是现在最主流、最基础的工作模式。
  3. Plan-and-Execute 模式:先花时间做一个完整的多步计划,然后再按计划一步步去执行,过程中可能会微调。这种模式适合长链条、复杂任务,比如写一个完整的项目代码。

再往上走,还有多Agent协作模式,比如一堆Agent各司其职,像开发团队一样有的写需求、有的写代码、有的测试,互相配合把一个大活儿完成。

5. 了解过Agent的设计范式吗?了解其他的Agent范式吗?

参考口述答案:

了解,这个基本和刚才的工作模式相关,但是从“方法论/设计思想”高度来说的:

最早、最简单的是ReAct范式,就是推理和行动交替进行,落地非常稳。

后来发现人做任务需要反思和修正,就出现了Reflexion范式,Agent 会把自己的上一次执行结果当成经验,自我反思改进,很像“失败是成功之母”。

然后还有Plan-and-Solve范式,强调“先把计划想全了再动”,避免走到半路发现走不通。

再往上有Tool-augmented范式,就是给模型配工具,本质让LLM学会“什么时候该用什么工具”。

以及现在热门的多Agent范式,包括角色扮演式协作、分层调度等,比如AutoGen、MetaGPT都是这个路线。

我个人感觉,这些范式不是对立的,实际系统经常是混合用的,比如ReAct里加反思,Plan里加工具调用等等。

6. Agent推理模式、推理模式的差异化设计、推理模式的选择机制

参考口述答案:

这个我分成三块说:

推理模式常见的有:

  • CoT 思维链:一步步推,适合逻辑题。
  • ToT 思维树:同时探索好几条路径,选最优的,适合需要搜索和创意的问题。
  • ReAct 推理+行动:推理中间插工具,适合需要外部信息的任务。
  • Reflexion 反思:任务失败后自动检查哪里错了,重新调整,适合需要高可靠性的场景。

差异化设计主要在于:

  • 要不要多路径探索;
  • 要不要和环境交互、调工具;
  • 允不允许失败重来;
  • 推理是“想到就做”还是“先想全再做”。

选择机制上:

一般不会一个Agent只绑一种推理模式,而是任务驱动切换。

比如简单问答用 CoT;复杂规划用 Plan+ReAct;如果允许高成本试错,就用 ToT 或加反思。

工程上,可以在提示词里描述任务类型,让模型自己选;也可以外层写规则调度,比如“先 ReAct 试一次,失败就上反思”。

7. 了解过市面上有哪些智能体Agent吗?

参考口述答案:

挺多的,我大概分几类说:

  • 开源/框架类:最早的 AutoGPT,接着是 MetaGPT(多角色写代码)、CrewAI(角色化协作)、微软的 AutoGen。
  • 低代码/平台类:Dify、字节的 Coze,基本都是拖拽式搭Agent,带RAG和插件,上手快。
  • 大厂产品:OpenAI 的 GPTs 和 Assistants API,可以直接定制带工具的Agent;谷歌有 Gemini 相关的Agent能力;国内百度、阿里钉钉也都推出了自己的智能体平台。
  • 垂类Agent:比如代码助手 Devin、Cursor这类,能自主改bug跑项目,也算是一种专业Agent。 目前的感觉是,整个行业正从“自己手写ReAct”慢慢走向“基于成熟框架和平台快速组装”。

8. Agent Loop 听说过吗?

参考口述答案:

听过,Agent Loop 就是Agent运行的主循环。

其实本质上就是大家常说的 “观察–思考–行动–观察” 的闭环。

具体来说:

  1. Agent 接收输入,先理解任务。
  2. 大脑(LLM)做推理,决定下一步要干什么。
  3. 如果需要,就调用工具执行动作。
  4. 拿到工具返回的结果,作为新的观察。
  5. 再回到推理环节,看任务完成了没,没完成就继续。

这就是完整的 Agent Loop,其实也是在工程上实现 ReAct 的基础循环。很多框架比如 LangGraph 就专门提供了对这种循环的图式支持,让状态管理更清晰。

9. 你认为当前Agent技术难以突破的核心瓶颈有哪些?

参考口述答案:

我主要看到这么几个痛点:

  1. 规划和推理的可靠性不够:模型经常做着做着就跑偏了,或者陷入死循环,特别在步骤多的任务上,一步错后面全完。
  2. 记忆与长上下文管理困难:多轮之后容易丢信息,或者记混了,做不到像人一样长期精准记忆。
  3. 工具调用不稳定:格式稍微不对就调用失败,比如JSON少个括号就崩,缺乏鲁棒的异常处理。
  4. 成本和时间不可控:多步循环频繁调大模型,又贵又慢,用户体验很受影响。
  5. 安全与可控性:自主行动一多,很难保证不会做错事,比如误删除、乱发消息,这在生产环境很要命。
  6. 评估体系不成熟:Agent 任务成功没有特别好的自动化标准,很多还靠人看,迭代很慢。 总的来说,就是 “想得不够稳、记不住、动手易翻车,还不敢放手让它干”。

10. 近半年一年大模型领域有哪些让你印象深刻的技术或产品进展?

参考口述答案:

印象深的还挺多的,我挑几个我觉得特别重要的:

  • MCP协议的出现和普及:Anthropic 推出的模型上下文协议,让工具调用有了统一接口,相当于给 Agent 配了个“万能插座”,大大降低了接入成本,生态一下子起来了。
  • 推理模型的大爆发:OpenAI 的 o1/o3,还有 DeepSeek R1 这些,把“慢思考”做进了模型本身,规划和多步推理能力强了一大截,对 Agent 意义很大。
  • 长上下文窗口越来越长:像 Gemini 2.5 Pro 直接到百万 token 级别,这让 Agent 的记忆和超长文档处理有了新的解法。
  • Agent与操作系统的结合:比如 Anthropic 的 Computer Use,能直接看屏幕、操作应用,以前只能调API,现在真能像人一样点鼠标了。
  • 多Agent协作产品化:以前多Agent更多是Demo,现在CrewAI、AutoGen这些框架越来越稳,实际在软件开发、调研报告等场景开始落地了。 整体感觉是:工具标准化、模型慢思考、环境泛化,这三件事把 Agent 从玩具慢慢推向可用。

11. 你常用哪些大模型相关的工具/框架?

参考口述答案:

平时用得比较杂,主要看场景:

  • 搭 Agent 我首推 LangChain + LangGraph,LangChain 管组件,LangGraph 管状态和循环,做复杂的 Agent Loop 很舒服。
  • 做 RAG 和知识记忆会用 LlamaIndex,数据接入和索引都很成熟。
  • 快速原型和演示一般用 Dify 或者 Coze,拖拽就能出效果,不用写很多代码,适合给别人看效果。
  • 多Agent协作试过 CrewAI 和微软的 AutoGen,两个思路稍有不同,CrewAI 上手更简单一些。
  • 模型侧用 vLLM 或者 Ollama 做本地部署和推理,调起来快,线上也用它搭服务。
  • 其他还经常用一些向量库比如 Chroma、Qdrant,做长记忆和检索。

这些组合基本能满足我日常从实验到 demo 落地的全流程。

12.Workflow 和 Agent

1. Workflow 和 Agent 有什么区别?

参考口述答案:

这个我可以打个比方:

  • Workflow 像一条固定流水线,或者一份标准操作手册。
  • Agent 像一个能随机应变的实习生,你告诉它目标,它自己想办法。

具体区别主要是这几点:

  • 决策方式:Workflow 的路径是事先画死的,“先做A,如果X就去B,否则去C”。Agent 是自己根据当前情况判断下一步该做什么。
  • 对不确定性的容忍度:Workflow 擅长处理确定性的、边界清晰的任务;Agent 更适合开放式目标,因为你根本没法提前穷举所有情况。
  • 控制感:Workflow 全程可预期、可审计,每一步你都知道。Agent 则更黑盒,中间可能走了你没想到的步骤。 简单记就一句话:Workflow 是“流程自动化”,Agent 是“目标驱动自主化”。

2. 什么情况下适合用 Workflow,什么情况下适合用 Agent?

参考口述答案:

选 Workflow 还是 Agent,我觉得核心看三点:确定性、变化频率、容错成本。

适合 Workflow 的情况:

  • 任务步骤非常固定,比如:新用户注册后自动发券、数据每天定时ETL、审批流转。
  • 边界明确,没有太多意外分支,异常情况你也都能提前想到。
  • 容错成本高,最好每一步都可控可回滚,比如财务、合规类操作。

适合 Agent 的情况:

  • 目标清楚但路径多变,比如“帮我调研一下竞争对手的最近动态”“帮我分析这份合同有什么风险”。
  • 需要大量理解、判断和工具动态组合的场景,比如客服、故障排查、代码写完后自己调试。
  • 没有办法提前写出完整流程图的复杂任务,必须依赖模型的理解能力去“随机应变”。

实际工作中,很多系统是外层用 Workflow 兜底主线,卡住关键节点,内层某些步骤挂载 Agent 解决脑力活,这样既稳又灵活。

3. 如何保证 Workflow 和 Agent 的成功率?

参考口述答案:

这俩的保证思路不太一样,我分着说:

保证 Workflow 成功率,基本是靠工程手段:

  • 步骤设计足够原子化,每个节点职责单一。
  • 丰富的异常捕获和重试机制,比如接口超时重试三次,不行就挂人工。
  • 关键节点加“检查点”或人工确认,钱和权限相关的要人拍板。
  • 完善的日志和监控,哪个节点挂了能立刻报警。

可以理解成 “把靠谱的流水线工程实践搬过来”。

保证 Agent 成功率,更多是在“教聪明”上:

  • 优化提示词和系统指令,让它正确理解任务边界。
  • 给高质量的工具描述和示例,让 Agent 知道什么情况该调什么工具。
  • 引入反思/自我纠错机制,比如失败后把错误信息喂回去让它自己修。
  • 设置循环步数上限、执行时长上限,防止死循环浪费资源。
  • 最后还得加一层安全围栏,比如只给它沙盒环境、敏感操作需人工审批。

可以总结为:Workflow 靠“流程的健壮性”,Agent 靠“智力的可控性”。

4. 智能体模式是模型的自我迭代还是工作流的方式?

参考口述答案:

这个我觉得要分开看:

从核心逻辑上讲,智能体模式本质是“模型驱动的自我迭代”。

也就是 Agent 会在 ReAct 等循环里,不断根据新观察结果做出决策,甚至反思修正之前的错误,这个过程是模型自己主导的,不是人工预先硬编码的路径。

但从工程实现上讲,它又必须依赖工作流来组织骨架。

比如用 LangGraph 这种框架,就是通过图来定义“推理→行动→观察”的状态流转,你可以把这个图看成一种“元工作流”。但这个工作流不是把具体业务步骤写死,而是提供一个循环和调度骨架,里面的决策和内容还是由模型动态生成的。

所以我的理解是:底层是模型自我迭代的动态循环,但工程上需要靠工作流框架来约束和承载,二者不是对立的。死板的工作流变不出智能体,但完全没有结构的自我迭代也无法稳定工作。

5. 工作流是怎么搭建的?怎么评测的?项目是怎么部署的?

这题我从三个点分别说:

怎么搭建:

  • 低代码/无代码平台:像字节的 Coze、Dify,还有海外的 Zapier、n8n。拖拽节点、连线、配置条件就搭好了,适合轻量级自动化和快速验证。
  • 代码框架:Python 生态里可以用 LangChain 的 Chain,或者更高级的 LangGraph 定义有状态的图;Node-RED 也是一种。
  • 大厂工具:比如阿里云的逻辑编排、AWS Step Functions 之类,适合和企业服务深度集成。 一般搭建流程:梳理业务逻辑 → 拆成原子步骤 → 确定分支条件 → 接入所需API/工具 → 调试异常路径。

怎么评测:

  • 端到端成功率:看整个流程跑完且结果正确的比例。
  • 节点级指标:每一步的执行耗时、失败率、重试情况。
  • 异常处理覆盖率:人为注入各种异常,看能否走到正确的降级或告警分支。
  • 业务指标:比如自动审批的准确率、人工介入率等。 评测工作流比 Agent 简单,因为路径固定,基本都是确定性比对。

怎么部署:

  • 定时触发:配合调度器(Cron、Airflow),定时跑批。
  • 事件触发:通过 Webhook、消息队列(Kafka、RabbitMQ)监听事件实时执行。
  • 作为服务部署:把工作流包装成 REST API,其他系统调这个API驱动流程。
  • 多环境管理:开发、测试、生产环境通过配置中心切换,敏感凭证走密钥管理服务。 部署后一般还要挂监控告警和日志追踪,保证出了问题能快速定位到哪个节点。

这样一套下来,工作流从搭建、评测到上线,还是比较工程化和标准化的,成熟度比Agent高不少。

接着之前的Agent面经,这里是 Workflow vs Agent 板块的口述式答案,同样保持通俗、能直接用的风格。

不定时更新~

本篇目录
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
  9. 09
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16

同作者面经

展开其余 4 篇收起其余 4 篇