昨天 19:27 已编辑门头沟学院人工智能发布于浙江

关注

2026年最新Agent面试(不含任何广放心阅读！

最近看每一篇面经中，都会被问到“对AI的了解”，如果2026年你想要从事高薪岗位，那么Agent一定不能错过！2026年就是Agent元年！继续给大家免费分享我的Agent知识库！复制搬运其他平台的人永远找不到工作！

Q1: 你如何定义一个基于 LLM 的智能体（Agent）？它通常由哪些核心组件构成？

LLM Agent 是以大语言模型为"大脑"，具备感知环境、自主决策和执行行动能力的系统。核心组件包括四个部分：

①规划模块（Planning）：将复杂任务分解为子任务序列，常用 CoT/ReAct/ToT 等策略；

②记忆模块（Memory）：短期记忆即当前对话上下文（存在 context window 中），长期记忆用向量数据库持久化存储历史经验；

③工具使用（Tool Use）：通过 Function Calling 调用外部 API、搜索引擎、代码执行器等扩展能力边界；

④行动模块（Action）：将 LLM 的决策转化为实际操作（API 调用、文件读写、发送消息等）。与普通 LLM 对话最大的区别是 Agent 有一个"感知-思考-行动"的循环，能自主迭代直到完成任务。

Q2: 请详细解释 ReAct 框架。

ReAct（Reasoning + Acting）是 2022 年 Google 提出的 Agent 核心范式，交替进行推理和行动。流程为：Thought（思考当前情况和下一步计划）→ Action（执行一个具体操作，如搜索/计算）→ Observation（观察操作返回的结果）→ 循环直到得出最终答案。相比纯 CoT（只思考不行动），ReAct 能获取外部信息纠正推理错误；相比纯 Action（盲目执行），ReAct 的 Thought 步骤提供了可解释的决策过程。实现上通常用 few-shot prompt 给出 Thought/Action/Observation 的格式示例，LLM 就能学会这个交互模式。LangChain 的 AgentExecutor 和 LangGraph 都内置了 ReAct 实现。局限性是链路长时容易累积错误，且每步都需要 LLM 推理，token 消耗大。

Q3: 在 Agent 的设计中，有哪些主流方法可以赋予 LLM 规划能力？

CoT（Chain-of-Thought）：让模型逐步推理，最基础的规划方式，适合线性任务。

ReAct：交替推理和行动，适合需要外部信息辅助决策的场景。

ToT（Tree of Thoughts）：将推理过程展开为树结构，每个节点是一个思路分支，通过评估函数选择最优路径，适合需要探索多种可能的复杂决策。

GoT（Graph of Thoughts）：在 ToT 基础上允许节点合并和循环，形成图结构，适合子任务之间有依赖关系的场景。

Plan-and-Execute：先用 LLM 生成完整计划（任务列表），再逐步执行。LangGraph 的实现中执行过程中可以动态修改计划。

Reflexion：执行后反思结果，失败时总结经验教训存入记忆，下次避免相同错误。实际中 Plan-and-Execute + Reflexion 组合使用效果较好。

Q4: 如何为 Agent 设计短期记忆和长期记忆系统？

短期记忆：即当前会话的上下文，直接存在 LLM 的 context window 中。优化手段包括：滑动窗口（只保留最近 N 轮）、摘要压缩（用 LLM 定期将历史对话总结为摘要）、关键信息提取（只保留实体/结论，丢弃过程）。

长期记忆：跨会话持久化存储。典型方案：①用向量数据库（Milvus/Chroma）存储历史对话的 Embedding，按语义检索相关历史；②用 Redis/数据库存储结构化信息（用户偏好、关键事实）；③用知识图谱存储实体关系

框架支持：Mem0 提供了开箱即用的长期记忆管理（自动提取、更新、检索），Zep 提供会话记忆+事实提取。实际中通常短期用 context window + 摘要，长期用向量库 + 结构化存储的混合方案。

Q5: LLM 是如何学会调用外部 API 或工具的？

主要两种路径：

①Function Calling / Tool Use（推理时能力）：在 API 请求中传入工具的 schema 定义（函数名、参数描述、类型约束），LLM 根据用户请求判断是否需要调用工具，输出结构化的调用指令（JSON 格式的函数名+参数）。这依赖模型在预训练或对齐阶段见过大量工具调用的数据。2026 年主流模型 GPT-5、Claude Opus 4.7/Sonnet 4.6、Gemini 2.5 Pro、Qwen3、DeepSeek-V3、Llama 4 都原生支持，且普遍支持并行工具调用（parallel tool calls）——一次返回多个 tool_use block，由调用方并发执行后批量回填 tool_result，链路延迟可降到 1/N。Claude 还支持 fine-grained tool streaming（边推理边输出工具参数）。

②微调（训练时能力）：用 SFT 数据集教模型识别工具调用时机和格式，数据集格式通常是 (user_query, thought, tool_call, tool_result, final_answer)。Toolformer 是早期工作；2025 年主流是用 Agentic SFT + RLVR 训练，让模型在沙盒中真实执行工具并基于轨迹奖励优化（如 ToRL、RAGEN、Search-R1）。实际中两者结合效果最好：用 Function Calling 提供工具定义，用微调提升调用准确率。MCP（Model Context Protocol） 已成为 2025-2026 工具协议事实标准，详见后文。

Q6: 有微调过 Agent 能力吗？数据集如何收集？

Agent 微调主要提升工具调用准确率和指令遵循能力。

数据集收集方法：①人工标注：标注员编写 (query, tool_call, result) 三元组，质量最高但成本大；②强模型蒸馏：用 Claude Opus 4.7 / GPT-5 / DeepSeek-V3 生成多样化的工具调用场景和正确的调用方式，再人工审核过滤，效率高；③真实日志挖掘：从线上 Agent 的成功执行日志中抽取高质量样本（rejection sampling 过滤失败轨迹）；④Self-Instruct / Agent-FLAN 风格：让模型在沙盒中自主探索工具调用场景，用 RLVR（可验证奖励）过滤错误轨迹。

关键注意点：数据多样性要够（覆盖各种工具组合和边界情况）、包含负样本（不需要调用工具的场景）、参数格式严格正确。

微调方式：通常用 LoRA/QLoRA 在 7B-14B 模型上微调，loss 只算 tool_call 和 answer 部分（忽略 system prompt 和 user input）。

Q7: 请比较 LangChain 和 LlamaIndex。

LangChain：通用 LLM 应用开发框架，核心是 Chain（链式调用）和 Agent（自主决策），提供丰富的组件（LLM/Prompt/Memory/Tools/Retriever 等）和集成。适合构建复杂的 Agent 工作流、多步骤推理、工具编排。LangGraph 是其状态机扩展，支持循环和条件分支。

LlamaIndex：以数据索引和检索为核心，擅长连接各种数据源（文档/SQL/API）并构建高效的查询管道。适合 RAG 场景，提供更细粒度的索引控制（树索引/关键词索引/知识图谱索引等）。

选型建议：如果核心需求是 RAG/数据查询，选 LlamaIndex；如果需要构建复杂 Agent 流程、多工具编排、多 Agent 协作，选 LangChain/LangGraph；两者可以混用——LlamaIndex 做检索引擎，LangChain 做 Agent 编排。

2026 趋势：模型厂商自家 SDK 强势崛起——Claude Agent SDK（Anthropic 2025 年发布，内置文件系统、Bash、Web 搜索、subagent、压缩等原语）和 OpenAI Agents SDK（Swarm 后继，支持 handoff、guardrails、tracing）已成为新项目的首选轻量替代，LangChain 的"重抽象+频繁破坏式更新"使其在生产侧份额下滑，常见做法是用 LangGraph 做状态机骨架 + 厂商 SDK 做具体能力调度。

Q8: 你用过哪些 Agent 框架？选型是如何选的？

2026 主流框架对比：

①Claude Agent SDK（Anthropic）：以 Claude Code 为代表的"通用编码 Agent"开源版，内置文件系统/Bash/Web Search/Subagent/Memory/上下文压缩，原生支持 MCP，工程化程度最高，是当前 SWE-bench 榜首方案的底座；

②OpenAI Agents SDK（Swarm 后继，2024 年底正式发布）：极简 Python SDK，核心抽象是 Agent + Handoff + Guardrails + Tracing，配合 Responses API 使用；

③LangGraph：状态机驱动，适合需要精确控制流程的场景，支持人机协作（HITL）节点和检查点持久化；

④Pydantic AI：类型安全优先，适合 Python 重度团队，结构化输出+依赖注入做得好；

⑤Mastra（TypeScript）：JS/TS 生态首选，工作流+RAG+评估一体；

⑥Smolagents（HuggingFace）：极简 Code-Agent 范式（让 LLM 直接写 Python 代码而非 JSON），步骤数显著减少；

⑦CrewAI：角色扮演式多 Agent；

⑧AutoGen v0.4（微软）：异步事件驱动重构版；

⑨Dify / Coze / 扣子：低代码平台。

选型依据：①编码/工程类 Agent → Claude Agent SDK；②OpenAI 生态/简洁 → OpenAI Agents SDK；③需要严格状态控制/HITL → LangGraph；④TS 项目 → Mastra；⑤多 Agent 角色协作 → CrewAI；⑥非技术快速搭建 → Dify/Coze。评价指标：任务成功率、平均步骤数、token 消耗/成本、P99 延迟、cache hit rate、用户满意度。实际中建议优先用厂商原生 SDK（生态绑定+工具丰富），需要跨模型时再用 LangGraph 抽象层。

Q9: 什么是多智能体系统？优势和复杂性？

多智能体系统（Multi-Agent System）是让多个专业化的 Agent 协同完成复杂任务。

优势：①专业分工——每个 Agent 专注一个领域（搜索 Agent、代码 Agent、分析 Agent），比全能 Agent 更准确；②并行执行——独立子任务可以同时进行，加速整体流程；③更长的有效推理链——单 Agent 超过 10 步容易累积错误，多 Agent 各自负责 3-5 步更稳定。

引入的复杂性：①通信开销——Agent 间消息传递增加延迟和 token 消耗；②协调难题——任务分配、冲突解决、结果合并需要额外的编排逻辑；③一致性——多个 Agent 可能给出矛盾结论；④调试困难——链路变长，排查问题更复杂；⑤成本翻倍——每个 Agent 都要调用 LLM。实际中不要过度设计，2-3 个 Agent 协作通常就够，超过 5 个管理成本急增。

Q10: 了解 A2A 和 MCP 协议吗？

MCP（Model Context Protocol）——Anthropic 2024 年 11 月开源的 LLM 与工具/数据源连接的开放协议，2025 年被 OpenAI、Google DeepMind、Cursor、Windsurf 等全面采纳，已成为事实标准。核心解决"M 个模型 × N 个工具"的集成爆炸问题：MCP Server 用统一协议（基于 JSON-RPC over stdio/SSE/HTTP）暴露 Tools（可调用函数）+ Resources（可读取数据）+ Prompts（可复用模板）+ Sampling（反向调用 LLM）+ Roots（文件系统访问范围）；MCP Client（Claude Desktop、Claude Code、Cursor、ChatGPT Desktop 等）只需一次集成就能消费全部 MCP Server。生态爆发：截至 2026 年初已有数千个 MCP Server（GitHub、Slack、Notion、Linear、Figma、Playwright、SQL 等），社区聚合站如 mcp.so、smithery.ai。安全考量：prompt injection、tool poisoning、token 泄漏是主要威胁，生产部署需做工具白名单+人工审批高危操作。

A2A（Agent-to-Agent）——Google Cloud 2025 年 4 月推出的 Agent 间互操作协议（已捐赠给 Linux Foundation），与 MCP 互补：MCP 管"Agent 调用工具/数据"，A2A 管"Agent 调用其他 Agent"。核心机制是 Agent Card（标准化能力描述卡片，类似 OpenAPI Spec），声明能力、输入输出格式、认证方式。两个 Agent 通过读取 Agent Card 即可互相调用，无需人工集成。典型组合：内部用 Claude Agent SDK 实现 Agent 逻辑 → 用 MCP 接入工具 → 用 A2A 暴露给其他系统调用。

面试加分点：能讲清 MCP 的五种 primitive（Tools/Resources/Prompts/Sampling/Roots）、知道 prompt injection 的缓解（resource indicators、用户确认、最小权限）、能区分 MCP 与传统 Function Calling 的差异（动态发现 vs 静态注册）。

Q11: 构建复杂 Agent 时最主要的挑战是什么？

可靠性是第一大挑战：LLM 的输出不确定性导致 Agent 行为不可预测——工具调用参数错误、规划路径不合理、陷入死循环。每一步 5% 的错误率在 10 步链路中累积到 40%+。

具体挑战：①错误累积和恢复——一步出错后续全废，需要反思和回滚机制；②延迟和成本——多步推理导致响应时间和 token 消耗远超单次对话；③评估困难——Agent 执行路径多样，很难自动化评估好坏；④上下文管理——长链路中 context window 不够用，关键信息被挤出去；⑤安全边界——Agent 有执行能力（写文件/调API），误操作后果严重。

应对：设置最大步骤数兜底、关键操作需人工确认、完善的日志和可观测性、用 guardrails 限制 Agent 能力范围。

Q12: 真实/模拟环境中的 Agent 与软件工具 Agent 有什么本质区别？

**具身 Agent（Embodied Agent）**的本质区别在于：

①不可逆性——机器人推倒杯子不能 ctrl+z，软件 Agent 调错 API 通常可以重试；

②连续动作空间——机械臂的角度/力度是连续值，而工具调用是离散的函数选择；

③实时性要求——物理环境需要毫秒级反应，软件 Agent 可以思考几秒再行动；

④感知噪声——摄像头/传感器数据有噪声和遮挡，API 返回的是结构化数据；

⑤安全约束更严——机器人误操作可能造成物理伤害。具身 Agent 通常需要：sim-to-real 迁移（在仿真中训练再部署到真实环境）、更强的世界模型（理解物理规律）、低延迟的感知-决策管道。

2026 主流范式：VLA（Vision-Language-Action）模型——把视觉、语言、动作统一到一个 Transformer 中端到端训练，已基本取代"高层 LLM 规划+低层传统控制"的两段式架构。代表工作：①Google RT-2（开创 VLA 概念）；②OpenVLA（开源 7B 模型，社区基线）；③Physical Intelligence π0 / π0.5（流匹配动作头，泛化能力突破）；④NVIDIA GR00T N1/N2（人形机器人基础模型，Isaac Lab 训练）；⑤Figure Helix（Figure 02 自研双系统 VLA，System 1 高频控制+System 2 慢思考）；⑥Tesla Optimus FSD-style 端到端。研究热点：跨本体迁移（cross-embodiment）、世界模型（Genie 2、V-JEPA 2）、合成数据（NVIDIA Cosmos、SimReady 资产库）。