面试高频：如何设计一个可落地的 Agent 系统？

一句话核心：Agent = LLM（大脑）+ Planning（规划）+ Memory（记忆）+ Tools（工具），通过"思考→行动→观察"循环自主完成复杂任务，从被动响应升级为主动执行，是 2025 年 Agent 元年的核心技术范式。

核心概念（术语表）

• Agent（智能体）：以 LLM 为核心，通过 Planning、Memory、Tools、Action 四大模块实现自主感知、规划、决策、执行和学习的完整系统，具备从"被动响应"到"主动规划执行"的根本性跃升。
• LLM（大语言模型）：Transformer 网络驱动的条件概率模型，P(token_n | token_1, ..., token_{n-1})，本质是无状态的推理引擎，是 Agent 的"大脑"和核心驱动力。
• Function Call（函数调用）：让 LLM 根据用户意图自动生成结构化 API 调用指令的机制，实现从"说怎么做"到"直接做"的跨越，底层依赖工具描述的 JSON Schema 约束。
• MCP（Model Context Protocol）：Anthropic 提出的模型上下文协议，解决 Agent 与外部工具/数据源连接的标准化问题，让一个 Agent 能调用多个 MCP Server 实现工具复用。
• ReAct（Reasoning + Acting）：将推理与行动结合的 Agent 工作模式，通过"思考→行动→观察"循环让 Agent 在动态环境中迭代优化，是主流的 Planning 策略之一。
• Memory（记忆系统）：Agent 存储、检索和管理信息的机制，包含短期记忆（上下文窗口）和长期记忆（向量数据库/知识图谱），突破 LLM 的上下文限制。
• A2A（Agent to Agent Protocol）：多个 Agent 之间通信的协议，与 MCP 互补——MCP 解决 Agent 与工具的连接，A2A 解决 Agent 与 Agent 的协作。
• Software 3.0：由自然语言提示驱动的软件开发范式，核心从"如何实现"转向"定义目标"，开发者从代码执行者转变为目标定义者。

阅读全文

历史背景 / 来源

• 2025 年被称为"Agent 元年"，行业从"LLM 为中心"转向"Agent 为中心"，大模型获得强大"认知"与"推理"能力后，核心瓶颈转向如何让 LLM 主动感知环境、调用工具、操作外部系统。
• Andrej Karpathy（Tesla AI 总监、OpenAI 研究科学家）在 2025 年 6 月 YC 演讲中提出："LLM 是新的操作系统内核（LLM OS），而 Agent 就是在这个新 OS 上运行的程序"，并系统阐述了 Software 1.0→2.0→3.0 的范式演进。
• Anthropic 在 2025 年推出 Claude Skills，持续受到开发者关注，代表了 Agent 技术的新方向——将 Prompt 封装为可复用的技能模块。
• Function Call 最早由 OpenAI 在 GPT-4 时代引入，逐步成为 Agent 调用外部工具的行业标准；MCP 协议由 Anthropic 在 2025 年提出，旨在解决工具生态的碎片化问题。

工作原理 / 核心机制（详细讲解）

整体思路：Agent 以 LLM 为认知核心，通过 Planning 模块将宏观目标拆解为可执行子任务，通过 Memory 模块存取历史交互和外部知识，通过 Tools 模块连接外部世界，通过 Action 模块执行具体操作，形成"思考→行动→观察"的闭环循环。

输入/输出：

• 输入：用户模糊的、抽象的、高层级的目标（如"帮我查明天北京天气，如果下雨就取消跑步计划"）
• 输出：具体的、可验证的、原子化的操作结果（如"已为您取消明天 7:00 的跑步计划"）

核心步骤详解：

第一步：意图理解（LLM）

• 输入：用户自然语言请求
• 处理：LLM 解析语义，识别用户真实意图
• 输出：结构化的任务描述

第二步：任务规划（Planning）

• 输入：结构化任务描述
• 处理：ReAct/CoT/ToT 等策略将宏观目标拆解为有序子任务链
• 输出：子任务列表 + 执行顺序
• 关键机制：ReAct = Reasoning（推理）+ Acting（行动），通过"Thought（思考）→ Action（行动）→ Observation（观察）"循环动态调整策略

第三步：记忆存取（Memory）

• 输入：当前任务上下文 + 历史交互记录
• 处理：短期记忆（会话窗口）+ 长期记忆（向量检索/知识图谱）的混合检索
• 输出：相关历史信息和背景知识

第四步：工具调用（Tools）

• 输入：子任务 + 可用工具列表
• 处理：Function Call 生成结构化调用指令，MCP 协议连接外部 API/数据库/代码执行器
• 输出：工具执行结果

第五步：结果执行与反馈（Action + Observation）

• 输入：工具执行结果
• 处理：LLM 评估结果是否符合预期，决定是否进入下一步或回退重试
• 输出：完成任务响应或进入下一轮循环

典型循环示例（电商旅行助理）：

1. 用户说"帮我规划去杭州的商务行程" → LLM 理解意图
2. Planning 拆解：查天气→订酒店→订机票→安排日程→设置提醒
3. Memory 检索：发现用户偏好靠窗座位、常用酒店品牌
4. Tools 调用：天气 API + 酒店预订 API + 机票 API + 日历 API
5. Action 执行：依次调用工具，返回完整行程
6. 循环迭代：每步结果反馈给 LLM 评估，动态调整后续计划

关键知识点（10-15 条 bullet）

• LLM 是"博学但足不出户的专家"，能给出建议但无法直接办事；Agent 是"拥有专家大脑、能跑腿办事的全能助理"
• LLM 四大天花板：① 只会说不会做 ② 没有记忆（上下文窗口限制） ③ 知识截止（训练数据有时效） ④ 不会规划（无法自动拆解复杂任务）
• Agent 核心公式：Agent = LLM (Reasoning) + Planning + Memory + Tool Use，通过四模块协作实现从"被动"到"主动"的跃升
• Software 1.0→2.0→3.0：1.0 写代码（C PU），2.0 训模型（GPU），3.0 写 Prompt（LLM），核心提问从"如何实现"→"需要什么数据"→"如何设定目标"
• Function Call 底层原理：通过预定义的 JSON Schema 描述工具接口，LLM 根据意图生成符合 Schema 的调用参数，本质是结构化输出的约束机制
• MCP 协议价值：解决 Agent 与外部工具连接的标准化问题，一个 Agent 可同时连接多个 MCP Server（如 GitHub、Slack、数据库），实现工具生态复用
• A2A vs MCP 分工：MCP = Agent 与工具的连接（垂直），A2A = Agent 与 Agent 的连接（水平），两者互补构成 Agent 网络
• ReAct 循环："Thought → Action → Observation"，通过观察结果动态调整下一步行动，适用于开放式、探索性任务
• Memory 两层架构：短期记忆（会话窗口，token 限制）+ 长期记忆（向量数据库，突破 token 上限），检索策略影响记忆命中率和系统响应
• Prompt Engineering 是 Agent 的"底层协议"：通过结构化文本指令将非确定性 LLM 输出约束为确定性系统接口，是构建稳定 Agent 的地基
• Agent 研发 vs 传统研发：传统是"命令式"（定义每一步如何做），Agent 是"目标导向式"（定义做什么和期望是什么），核心产出从代码变为 Prompt + 架构
• Agent 调试核心：追踪和可视化完整思维链（Chain of Thought），而非传统 Debug 断点检查堆栈
• Agent 可靠性保障：采用"规划-执行-评估"三阶段、设置最大循环次数防止无限重试、重要操作需要人工确认
• Skills vs Prompt：Skill 是封装好的、可复用的、带有状态管理的 Prompt 模块；Prompt 是单次交互的文本指令
• RAG + Agent 互补：RAG 提供知识检索能力，Agent 提供规划和执行能力，RAG 是 Agent 的"外部知识库"

应用场景（3-5 个真实例子）

• 场景 1 - 电商资损防控：大淘宝技术团队用 Agent 实现自动化风险识别，Agent 自动拆解"大促商品文案审核"任务，调用广告法知识库、平台规范库进行合规检查，输出审计报告 + 风险等级（高/中/低）+ 修改建议，审核效率提升数倍，漏检率降低 60%+
• 场景 2 - 私人旅行助理：用户说"规划去杭州商务行程"，Agent 自动完成查天气→订酒店（偏好靠窗）→订机票→添加日历→设置提醒的全流程，从 10+ 分钟手动操作压缩到 1 分钟自动完成
• 场景 3 - 自动化代码审查：Agent 调用 GitHub API 获取 PR → 调用静态分析工具 → 调取代码规范文档 → 生成审查意见，覆盖 80%+ 常见问题，审查周期从 2 天缩短到 2 小时
• 场景 4 - 企业客服 Agent：Agent 理解用户问题后，自动调用订单系统、FAQ 知识库、退款流程等多个 MCP Server，串联多个内部系统完成复杂咨询，无需用户在不同系统间跳转
• 场景 5 - 多 Agent 协作编程：一个 Agent 负责代码生成，另一个 Agent 负责代码审查，第三个 Agent 负责测试生成，通过 A2A 协议通信协作，模拟真实开发团队的分工

常见误区 / 踩坑（4-6 条）

• ❌ 误区 1：Agent 就是 LLM 加工具
  ✅ 正解：Agent 是 LLM + Planning + Memory + Tools 的完整系统架构，单纯加工具只是"增强版 LLM"，没有规划能力和记忆能力的 Agent 无法处理复杂任务

• ❌ 误区 2：Function Call 就是让 LLM 随意调用任何 API
  ✅ 正解：Function Call 需要预定义工具的 JSON Schema 描述，LLM 只能在给定的工具列表中选择，且调用参数受 Schema 约束，否则会导致安全问题

• ❌ 误区 3：Agent 可以无限循环执行任务
  ✅ 正解：必须设置最大循环次数（如 10 次）和超时机制，防止 Agent 在规划失败时陷入无限重试，实际落地中约 15% 的任务需要人工介入兜底

• ❌ 误区 4：MCP 和 A2A 是竞争关系
  ✅ 正解：MCP 和 A2A 解决不同问题——MCP 解决 Agent 与工具的连接（垂直），A2A 解决 Agent 与 Agent 的协作（水平），两者是互补关系

• ❌ 误区 5：Agent 研发不需要测试
  ✅ 正解：Agent 研发依赖"评估集"，需要大量真实场景测试定义"什么是好结果"，与传统代码测试完全不同，是实验驱动/探索式的研发模式

• ❌ 误区 6：所有任务都应该用 Agent
  ✅ 正解：Agent 适用于开放式、探索性、多步骤任务；简单确定性任务（如"3+5=？"）用 LLM 直接调用更高效，Agent 的规划开销反而是浪费

性能 / 复杂度（数据驱动）

• Function Call 延迟：单次调用增加 50-200ms（依赖 LLM 输出长度），但减少后续重试和错误处理时间
• Memory 检索延迟：向量检索 O(log n)，100 万条记录检索约 10-50ms；关键词检索 O(n)，但精确率高
• ReAct 循环开销：每次循环增加 1-3 个 LLM 调用，复杂任务可能需要 5-10 个循环，总延迟 = 单次延迟 × 循环次数
• MCP Server 连接：首次连接建立 TCP 长连接约 100-500ms，后续调用延迟接近本地函数调用

与替代方案对比：

• 方案 A - 传统 Workflow（硬编码流程）：时间复杂度 O(1)，固定流程，无规划开销，但无法处理开放性任务；适用边界：任务步骤固定、无分支、无需动态调整
• 方案 B - 纯 LLM 调用：时间复杂度 O(1)，无工具调用开销，但输出不可控、无法执行操作；适用边界：单次问答、内容生成、知识总结
• 方案 C - Agent（本方案）：时间复杂度 O(k)，k = 循环次数，无上限但通常 5-10 次收敛；适用边界：开放式任务、多步骤、需要动态调整
• 临界点：任务步骤 < 3 且固定 → Workflow 更优；任务步骤 > 3 且有分支 → Agent 更优

性能数字：

• 电商文案审核 Agent：处理 1000 条文案，漏检率从 8% 降至 3%，审核时间从 2 小时缩短到 15 分钟
• 旅行规划 Agent：全流程自动化，用户操作从 10+ 步减少到 1 步，任务完成率 > 85%

与相关概念的区别（至少 3 对）

• vs LLM（直接调用）：

  • 维度 1（能力）：LLM 只能"说"，Agent 能"做"；LLM 告诉你怎么做，Agent 直接帮你做完
  • 维度 2（记忆**：LLM 无状态依赖上下文窗口，Agent 有短期+长期记忆突破限制
  • 维度 3（适用）：LLM 适合问答/生成，Agent 适合复杂任务自动化
  • 怎么选：简单问答用 LLM，复杂任务自动化用 Agent

• vs Workflow（工作流）：

  • 维度 1（灵活性**：Workflow 流程硬编码固定，Agent 动态规划可应对变化
  • 维度 2（适应性**：Workflow 遇到分支需要预设，Agent 可实时决策
  • 维度 3（适用**：Workflow 适合步骤固定的可重复任务，Agent 适合开放式探索任务
  • 怎么选：固定流程用 Workflow，动态决策用 Agent

• vs RAG（检索增强）：

  • 维度 1（定位**：RAG 是 Agent 的"外部知识库"，解决知识时效性问题；Agent 是 RAG 的"执行器"，将检索结果转化为行动
  • 维度 2（能力**：RAG 专注检索准确性，Agent 专注任务规划和执行
  • 维度 3（关系**：RAG + Agent = 知识检索 + 行动执行，两者互补
  • 怎么选：知识密集型任务用 RAG，行动密集型任务用 Agent，两者结合效果最佳

• vs Skills（技能）：

  • 维度 1（粒度**：Skill 是封装好的、可复用的、带状态的 Prompt 模块；Prompt 是单次交互
  • 维度 2（复用**：Skill 可被多个 Agent 共享，Prompt 是 Agent 内部定义
  • 维度 3（管理**：Skill 支持版本管理、参数配置，Prompt 相对简单
  • 怎么选：需要复用的能力封装为 Skill，一次性能力用 Prompt

进阶 / 面试加分项

• 最新进展：Claude Skills 代表了 Agent 技能化的方向——将 Agent 能力封装为可复用模块，支持版本管理和动态加载；多 Agent 协作（A2A 协议）是 2025-2026 年的热点，一个 Agent 负责规划、一个负责执行、一个负责验证
• 业界争议/未解决：
  1. Agent 的"幻觉漂移"问题——多步推理中错误会累积放大，如何建立有效的自我纠错机制仍是难题
  2. Agent 的可解释性——用户无法理解 Agent 为什么做了某个决定，思维链可视化仍是初级阶段
  3. Agent 的安全性——恶意 Prompt 注入、工具滥用问题尚无完美解决方案
• 一句话送给候选人："Agent 不是银弹，它是把锤子——关键是你要知道什么任务是钉子、什么任务是螺丝刀"

---

金句总结

"LLM 是新的操作系统内核，Agent 是运行在这个新 OS 上的程序。" —— Andrej Karpathy

"Agent 研发的核心，不是写代码，而是设计目标和评估标准。" —— 大淘宝技术

"LLM 告诉你怎么做，Agent 直接帮你做完。" —— 卡码笔记

面试如何回答

🟢 LLM 和 Agent 有什么区别？Agent 比 LLM 多了什么？

回答要点：

LLM 本质是一个条件概率模型 P(token_n | token_1...token_{n-1})，是无状态的推理引擎，只能"被动响应"给出文本答案。Agent 则是以 LLM 为核心大脑，加上 Planning（规划）、Memory（记忆）、Tools（工具）、Action（行动）四大模块，实现"主动规划与执行"。简单来说：LLM 告诉你怎么做，Agent 直接帮你做完。比如查天气任务，LLM 会说"您可以打开天气 App 查看"，而 Agent 会直接调用天气 API 返回结果，再根据结果决定是否取消跑步计划。面试时可以补充：LLM 是 Agent 的技术基石，但 Agent 是将 LLM 认知能力转化为实际生产力的完整应用系统。

🟡 Agent 有哪些工作模式？ReAct 是什么？请举例说明

回答要点：

Agent 主流工作模式有三种：ReAct（推理+行动）、CoT（链式推理）、ToT（树状搜索）。ReAct 是最常用的模式，通过"Thought（思考）→ Action（行动）→ Observation（观察）"的循环，让 Agent 在动态环境中迭代优化。举例：用户说"帮我查杭州天气，如果下雨就取消室外会议"。ReAct 循环：第一轮 Thought="我需要先查杭州天气"，Action="调用天气 API"，Observation="杭州明天中雨"；第二轮 Thought="降雨需要取消室外会议"，Action="调用日历 API 删除室外会议"，Observation="删除成功"；第三轮 Action="回复用户已取消"。ReAct 的优势是可以根据观察结果动态调整策略，适合开放式探索任务；局限是每次循环都增加 LLM 调用开销，复杂任务可能需要 5-10 个循环。

🟡 Function Call 是什么？底层怎么实现的？

回答要点：

Function Call 是让 LLM 根据用户意图，自动生成符合预定义 Schema 的结构化 API 调用指令的机制。底层实现分为三步：第一步，预定义工具接口，用 JSON Schema 描述工具名称、参数类型、参数描述、返回值格式，比如描述"获取天气"工具需要 city 参数（string 类型）；第二步，LLM 接收用户请求后，根据工具描述判断是否需要调用工具，生成符合 Schema 的调用参数（而非自然语言）；第三步，系统解析调用指令，执行真实 API，返回结果给 LLM 生成最终响应。Function Call 的本质是将 LLM 的非确定性输出约束为确定性系统接口，解决了"LLM 只会说不会做"的问题。需要注意的是，LLM 只能在给定的工具列表中选择，调用参数受 Schema 约束，无法随意调用任何 API，这既是安全保障也是能力边界。

🟡 MCP 协议是什么？解决什么问题？和 A2A 有什么区别？

回答要点：

MCP（Model Context Protocol）是 Anthropic 在 2025 年提出的模型上下文协议，旨在解决 Agent 与外部工具/数据源连接的标准化问题。核心价值：一个 Agent 可以同时连接多个 MCP Server（如 GitHub、Slack、数据库），每个 Server 提供一类工具能力，Agent 根据任务需求动态选择调用。这解决了工具生态碎片化问题——过去每个工具都需要独立集成，现在通过 MCP 协议实现即插即用。A2A（Agent to Agent Protocol）与 MCP 是互补关系：MCP 解决 Agent 与工具的连接（垂直方向），A2A 解决 Agent 与 Agent 的协作（水平方向）。举例：电商客服 Agent 通过 MCP 连接订单系统、FAQ 知识库、退款流程；多个 Agent 通过 A2A 协作——一个负责理解意图，一个负责执行操作，一个负责验证结果。

🔴 如果让你从零设计一个 Agent 系统，你会怎么做？请给出整体架构

回答要点：

设计 Agent 系统分为五层架构：

第一层（核心）：LLM 作为认知引擎，负责意图理解、推理判断、决策生成。选型取决于任务复杂度——简单任务用 GPT-3.5 级别，复杂推理用 GPT-4 或 Claude。

第二层（规划层）：Planning 模块负责任务拆解和策略选择。推荐 ReAct 模式，设置最大循环次数（通常 5-10 次）防止无限重试。对于可重复任务可混合 Workflow 模式。

第三层（记忆层）：Memory 模块分为短期记忆（会话窗口，存放当前任务上下文）和长期记忆（向量数据库，存放历史交互和外部知识）。记忆策略直接影响 Agent 表现——需要平衡检索精度和响应速度。

第四层（工具层）：Tools 模块通过 Function Call + MCP 协议连接外部能力。工具描述要用 JSON Schema 精确定义，包含参数类型、取值范围、错误处理。

第五层（执行层）：Action 模块负责最终执行和结果评估。重要操作建议加入人工确认机制，可靠性目标设定 > 85% 任务完成率。

核心设计原则：模块化（便于单独优化）、可观测（完整记录思维链）、可回滚（失败时能恢复到安全状态）。

🟡 Agent 的记忆系统怎么设计？短期记忆和长期记忆有什么区别？

回答要点：

Agent 记忆系统分为三层架构：

第一层：上下文窗口（短期记忆）。直接存在 LLM 的输入里，每次对话都携带，优点是零延迟，局限是受 token 上限限制（通常 4K-128K）。适合存放：当前任务目标、最近 3-5 轮对话内容、关键中间结果。

第二层：向量数据库（长期记忆）。突破 token 限制，存储历史交互和外部知识。检索时将当前上下文编码为向量，在向量库中做相似度搜索。优点是容量无限，局限是检索精度依赖 embedding 模型质量，且增加 10-50ms 延迟。适合存放：用户偏好、历史成功案例、行业知识库。

第三层：知识图谱（结构化记忆）。以图结构存储实体关系，检索可做多跳推理。比如"用户买过某品牌手机→该品牌有耳机产品→推荐搭配购买"。适合复杂推理场景。

面试加分点：记忆的"写入时机"比"存储容量"更重要。推荐策略：任务完成后提取关键结论写入长期记忆；定期做记忆压缩，避免无效信息堆积；设置记忆衰减机制，过期信息自动清理。

🟡 Function Call、MCP、Skills 三者有什么区别？如何协作？

回答要点：

三个概念解决不同层次的问题：

Function Call（函数调用）：LLM 层面的能力，让 LLM 能生成结构化的 API 调用指令。类比："让 LLM 长出一双手"，解决"LLM 只会说不会做"的问题。

MCP（Model Context Protocol）：系统层面的协议，让 Agent 与外部工具实现标准化连接。类比："USB 接口标准"，解决工具集成的碎片化问题，一个 Agent 可同时连接多个 MCP Server。

Skills（技能）：应用层面的封装，将 Prompt + 工具 + 记忆打包成可复用的模块。类比："封装好的函数库"，支持版本管理和动态加载。

协作关系：Skills 封装业务能力，内置 MCP 连接外部工具，Function Call 触发具体 API 调用。举例：开发"商品审核 Skill"，内部定义审核流程（Prompt）、调用广告法库（MCP）、生成审查报告（Function Call）。Skills 是最高抽象，MCP 和 Function Call 是基础设施。

🟢 Agent 和 Workflow 有什么区别？什么场景用 Workflow，什么场景用 Agent？

回答要点：

Workflow（工作流）和 Agent 是两种不同的任务执行范式：

Workflow 是"命令式"——预先定义每一步的走向和操作，类似流程图或状态机，输入固定输出就固定。优势是确定性高、可预测、可测试；局限是缺乏灵活性，遇到分支或异常只能预设处理。

Agent 是"目标导向式"——定义目标是什么，由 LLM 动态决定执行步骤和工具选择。优势是能处理开放式任务、适应变化；局限是有不确定性，需要设置兜底机制。

选择原则：任务步骤 < 3 且完全固定 → Workflow；任务步骤 > 3 且有分支/需要动态决策 → Agent。

举例："用户下单后自动发货"流程固定用 Workflow；"帮用户规划旅行行程"需要根据天气、偏好、预算动态调整用 Agent。

面试加分点：Hybrid 模式最常见——Workflow 定义主流程骨架，Agent 处理流程中的开放式子任务。比如电商场景：下单→支付（Workflow）→智能客服咨询（Agent）→物流查询（Workflow）。

🔴 Agent 有哪些常见问题？如何保障可靠性和安全性？

回答要点：

Agent 落地面临三大挑战：

第一，幻觉漂移：多步推理中错误会累积放大，比如第一步理解错了，后续所有规划都基于错误前提。解决方案：每步加入置信度评估，低置信度时要求人工确认或回退重试。

第二，无限循环：Agent 在规划失败时可能反复尝试同一组无效操作。解决方案：必须设置最大循环次数（通常 5-10 次）和超时机制，记录已尝试方案避免重复。

第三，Prompt 注入：恶意用户通过特殊输入让 Agent 执行非预期操作。解决方案：输入要做严格校验和清洗，敏感操作需要二次确认。

可靠性保障实践：采用"规划-执行-验证"三阶段，重要操作执行后验证结果是否符合预期；建立完善的日志和回滚机制；设定可靠性 SLO（如任务完成率 > 85%），不达标的场景用人工兜底。

面试金句："Agent 不是银弹，是有成本的锤子——要清楚什么任务值得用它敲，以及敲坏了怎么办。"