# AI Agent 面试题 - 前沿技术与协议篇
> 基于 AgentGuide 项目整理 | 适用：Agent 开发工程师 & 架构师
---
## 一、LLM 与 Agent 的本质区别
**Q1: LLM 和 Agent 有什么区别？为什么说 Agent = LLM + 工具 + 记忆 + 规划？**
- **难度**: ⭐⭐
- **岗位**: 通用
- **公司**: 所有公司(必考)
**核心区别**:
| 维度 | LLM | Agent |
|:---|:---|:---|
| **本质** | 条件概率模型 P(token_n \| token_1...token_{n-1}) | 自主决策执行系统 |
| **状态** | 无状态，每次调用独立 | 有状态，可维护记忆 |
| **能力** | 只会说，不会做 | 能说会做，调用工具执行 |
| **知识** | 知识截止，无法获取实时信息 | 可检索、可更新知识 |
| **规划** | 线性回答，不会自主拆解任务 | 可自主规划多步骤任务 |
**Agent 四模块详解**:
┌─────────────────────────────────────────┐
│ Agent 完整架构 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ LLM │ │ 规划 │ │ 记忆 │ │
│ │ (大脑) │ │ (思考) │ │ (存储) │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ └─────────────┼─────────────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ 工具 │ │
│ │ (执行) │ │
│ └─────────┘ │
│ │
└─────────────────────────────────────────┘
**面试示例对比**:
任务：查明天北京天气，如果下雨就取消日历里的跑步计划
| 角色 | 实际行为 |
|:---|:---|
| **LLM** | "您可以打开天气 App 查询北京明天天气，如果降雨概率超过 60% 建议取消户外运动..." |
| **Agent** | 1. 调用天气 API → 明天北京中雨<br>2. 调用日历 API → 找到明天 7:00 跑步计划<br>3. 调用日历 API → 删除该计划<br>4. 回复："明天北京有雨，已为您取消跑步计划。" |
**面试加分点**: LLM 告诉你怎么做，Agent 直接帮你做完，这就是本质区别。
---
**Q2: Agent 和 Workflow 有什么区别？如何判断一个任务该用 Agent 还是 Workflow？**
- **难度**: ⭐⭐⭐
- **岗位**: 开发岗重点
- **公司**: 字节、阿里、腾讯
**核心区别：控制权在谁手里？**
| 维度 | Workflow | Agent |
|:---|:---|:---|
| **控制者** | 代码/开发者 | LLM |
| **流程** | 预定义，写死在代码里 | 动态规划，LLM 自主决定 |
| **Token 消耗** | 低（约 1x） | 高（约 4-8x） |
| **可预测性** | 高 | 低 |
| **灵活性** | 低 | 高 |
| **调试难度** | 容易 | 困难 |
| **适合任务** | 固定流程（订单处理、报表生成） | 开放式目标（研究分析、复杂客服） |
**选型决策树**:
任务分析
│
├── 流程是否固定且明确？
│ ├── 是 → Workflow（稳定可控）
│ └── 否 → Agent（灵活适应）
│
└── 是否需要处理大量异常情况？
├── 是 → Agent 或 混合架构
└── 否 → Workflow
**生产实践：混合架构最常见**
智能客服系统示例:
用户问题
│
├── 简单问题（FAQ）→ Workflow 直接回答
│
├── 复杂问题 → Agent 自主分析决策
│
└── 投诉工单 → 直接升级人工
**面试加分点**: 大多数生产系统是 Workflow + Agent 的混合架构，Workflow 提供稳定骨架，Agent 处理异常和复杂情况。
---
## 二、Agent 工作模式详解
**Q3: Agent 有哪些主流工作模式？ReAct、Plan-and-Execute、Reflection、Multi-Agent 各自的特点是什么？**
- **难度**: ⭐⭐⭐
- **岗位**: 通用
- **公司**: 字节、阿里、腾讯(高频)
### 模式一：ReAct（推理 + 行动）
**核心循环**: Thought → Action → Observation → ... → Answer
```python
# ReAct 伪代码示例
class ReActAgent:
def run(self, task, max_steps=15):
steps = 0
seen_actions = []
while steps < max_steps:
thought, action = self.llm_think(task, history)
# 防死循环检测
if action in seen_actions[-3:]:
return self.llm_summarize("工具持续失败，基于已有信息给出答案")
seen_actions.append(action)
observation = self.execute(action)
steps += 1
return "达到最大步数限制"
优点: 透明可审计、灵活适应、通用性强
缺点: Token 消耗大、可能死循环、延迟高
防死循环三要素:
- 最大步数限制（通常 15 步）
- 重复动作检测（连续 3 次相同动作退出）
- 超时控制（设置最大执行时间）
模式二：Plan-and-Execute（先规划再执行）
两阶段工作:
- Planner LLM: 一次性生成完整计划
- Executor: 按计划逐步执行
用户请求: "做一份竞品分析"
│
▼
Planner 生成计划:
├── 1. 搜集竞品列表
├── 2. 逐个分析功能
├── 3. 对比价格策略
├── 4. 分析用户评价
└── 5. 生成对比报告
│
▼
Executor 逐步执行（每步无需重新思考全局）
Token 消耗对比: ReAct 每步思考全局（100%）vs Plan-and-Execute 规划一次（约 20%）
模式三：Reflection（自我反思）
核心思想: 一个 Agent 生成，另一个 Agent 审查，循环迭代
Writer Agent → 生成内容
│
▼
Reviewer Agent → 发现问题（安全漏洞、性能问题）
│
▼
Writer Agent → 修改
│
▼
Reviewer Agent → 确认通过
│
▼
最终输出
适用场景: 代码生成、法律文书、学术论文、创意写作
面试加分点: Reflection 可用于自我校正幻觉，当 Agent 发现事实存疑时，触发"验证反思"调用搜索工具核实。
模式四：Multi-Agent（多智能体协作）
┌─────────────────────────────────────────┐
│ Multi-Agent 架构 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Orchestrator │ │
│ │ (协调 Agent)│ │
│ └──────┬──────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Research│ │Coder │ │Reviewer│ │
│ │ Agent │ │Agent │ │ Agent │ │
│ └──────┘ └──────┘ └──────┘ │
│ │
└─────────────────────────────────────────┘
主流框架对比:
| 框架 | 特点 | 适用场景 |
|---|---|---|
| LangGraph | 图结构编排，状态机模型 | 需要精细控制的复杂工作流 |
| CrewAI | 角色化 Agent，任务分工 | 团队协作场景，上手简单 |
| OpenAI SDK | Handoff 机制，工具调用原生支持 | 官方推荐，生态完善 |
| AutoGen | 微软出品，对话式多 Agent | 研究型项目友好 |
面试加分点: Anthropic 提醒——不要过早引入 Multi-Agent，一个强大的单 Agent 往往比多个简单 Agent 更稳定、更省钱。
三、Function Call 底层实现
Q4: Function Call 是什么？底层怎么实现？LLM 真的在执行函数吗？
- 难度: ⭐⭐⭐
- 岗位: 开发岗重点
- 公司: 所有公司(高频)
关键认知: LLM 不执行函数！
Function Call 是让 LLM 输出结构化的工具调用指令，再由应用程序实际执行。
Function Call 四步流程
Step 1: 定义工具
{
"tools": [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的实时天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如：北京、上海"
},
"date": {
"type": "string",
"description": "日期，格式 YYYY-MM-DD"
}
},
"required": ["city"]
}
}
}]
}
Step 2: LLM 生成调用指令
{
"tool_calls": [{
"id": "call_abc123",
"type": "function",
"function": {
"name": "get_weather",
"arguments": "{\"city\": \"北京\", \"date\": \"2025-04-11\"}"
}
}]
}
Step 3: 应用程序解析执行
def handle_tool_calls(tool_calls):
results = []
for call in tool_calls:
func_name = call.function.name
args = json.loads(call.function.arguments)
if func_name == "get_weather":
result = weather_api.get(args["city"], args.get("date"))
elif func_name == "search_calendar":
result = calendar_api.search(args["query"])
results.append({
"tool_call_id": call.id,
"role": "tool",
"content": json.dumps(result)
})
return results
Step 4: 结果传回 LLM 生成最终回答
messages.append({"role": "assistant", "tool_calls": tool_calls})
messages.extend(tool_results)
final_response = client.chat.completions.create(
model="gpt-4o",
messages=messages
)
Parallel Function Call（并行调用）
{
"tool_calls": [
{"id": "call_1", "function": {"name": "get_weather", "arguments": "{\"city\":\"北京\"}"}},
{"id": "call_2", "function": {"name": "search_calendar", "arguments": "{\"date\":\"明天\"}"}},
{"id": "call_3", "function": {"name": "get_traffic", "arguments": "{\"route\":\"上班路线\"}"}}
]
}
性能对比:
- 串行执行: T = T1 + T2 + T3
- 并行执行: T = max(T1, T2, T3)
各厂商格式对比
| 特性 | OpenAI | Anthropic Claude |
|---|---|---|
| 工具定义 | tools + function |
tools + input_schema |
| 调用输出 | tool_calls 数组 |
tool_use content block |
| 结果传回 | role: "tool" |
role: "user" + tool_result block |
面试核心点: LLM 只输出"我想调用什么"的指令，真正执行的是你的应用程序。这个设计保证了安全性——LLM 无法绕过代码直接操作系统。
四、MCP 协议详解
Q5: MCP 是什么协议？它解决了什么问题？和 Function Call 有什么本质区别？
- 难度: ⭐⭐⭐⭐
- 岗位: 开发岗重点
- 公司: 字节、阿里、腾讯(新兴热点)
MCP 解决的根本问题: N × M 爆炸
没有 MCP 之前:
- 3 个应用 × 3 个工具 = 9 套集成代码
- 10 个应用 × 20 个工具 = 200 套代码
有了 MCP 之后:
- 每个应用只需接入 MCP 协议
- 每个工具只需实现一个 MCP Server
- 总共 N + M 套代码
MCP 架构三角色
┌─────────────────────────────────────────┐
│ MCP 架构 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │MCP Host │◄────►│MCP Client│ │
│ │(AI应用) │ │(翻译官) │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ └────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ MCP Server │ │
│ │ (工具能力提供) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────┘
| 角色 | 说明 | 示例 |
|---|---|---|
| MCP Host | 使用的 AI 应用 | Claude Desktop、Cursor、你的 Agent |
| MCP Client | 负责和 Server 通信的"翻译官" | 内置于 Host |
| MCP Server | 暴露具体工具能力的服务端 | GitHub MCP Server、Slack MCP Server |
MCP 提供的三类能力
| 类型 | 说明 | 示例 |
|---|---|---|
| Tools | 可执行的操作 | 发消息、查数据、写文件 |
| Resources | 可读的数据源 | 文档、代码库、数据库 |
| Prompts | 预设提示词模板 | 代码审查模板、SQL 生成模板 |
MCP 工具发现机制
Agent 启动
│
▼
扫描 MCP Server 列表
│
▼
发送 tools/list 请求到每个 Server
│
▼
接收工具列表和描述
│
▼
注入 LLM 上下文
│
▼
运行时动态发现新能力
核心优势: Agent 可以在运行时动态发现新能力，不需要重新部署代码。
MCP 安全性设计
| 层级 | 机制 | 说明 |
|---|---|---|
| 第一层 | 能力声明 | Server 明确声明提供哪些工具 |
| 第二层 | 授权控制 | 敏感操作要求人工确认 |
| 第三层 | 审计追踪 | 所有工具调用都有日志 |
MCP 底层协议
| 通信方式 | 协议 | 适用场景 |
|---|---|---|
| 本地通信 | stdio（标准输入输出） | 本地工具 |
| 远程通信 | HTTP + SSE | 远程服务、流式支持 |
| 消息格式 | JSON-RPC 2.0 | 标准规范 |
面试加分点: MCP 让工具集成从 N×M 变成 N+M，且支持运行时动态发现，是 Agent 工具生态的重要基础设施。
五、Skills 与 Prompt 的区别
Q6: Skills 是什么？和 System Prompt 有什么区别？如何设计一个 Skill？
- 难度: ⭐⭐⭐
- 岗位: 开发岗重点
- 公司: 字节、阿里
Skills 解决的问题
给 Agent 一堆工具还不够，它还需要知道：
- 遇到代码审查，该用什么标准？
- 写 SQL 查询时，DBA 的最佳实践是什么？
- 回复客户时，品牌的语气要求是什么？
这些领域专家经验，就是 Skills 要编码的东西。
Skills vs System Prompt
| 维度 | System Prompt | Skills |
|---|---|---|
| 作用范围 | 全局，一直生效 | 按需激活，场景触发 |
| 内容 | 通用行为规范 | 特定领域专业指导 |
| 激活方式 | 每次都加载 | 匹配场景才加载 |
| 可维护性 | 随功能增多变复杂 | 模块化，各自独立 |
| 典型内容 | "你是一个助手..." | 代码审查流程/标准 |
Skill 设计示例
# code_review_skill.yaml
name: "Code Review Expert"
description: "专业的代码审查技能，用于发现代码中的安全漏洞和性能问题"
triggers:
- keywords: ["review", "代码审查", "code review"]
- file_patterns: ["*.py", "*.js", "*.go"]
instructions: |
你是一位资深代码审查专家，请按照以下标准审查代码：
## 审查维度
1. **安全性**: 检查 SQL 注入、XSS、敏感信息泄露
2. **性能**: 检查 N+1 查询、内存泄漏、算法复杂度
3. **可维护性**: 检查代码重复、命名规范、注释完整性
4. **最佳实践**: 检查是否符合语言/框架的惯用写法
## 输出格式
- 🔴 严重问题（必须修复）
- 🟡 建议优化（推荐修复）
- 🟢 良好实践（值得保持）
tools:
- security_scanner
- performance_profiler
Skill 生命周期
用户输入
│
▼
Skill Router 匹配触发条件
│
▼
加载对应 Skill 的 instructions
│
▼
注入 LLM 上下文 + 关联 Tools
│
▼
执行并输出
面试加分点: Skills 是 Prompt 工程的高级形态，将领域知识模块化、可复用，支持按需加载，解决了 System Prompt 臃肿难维护的问题。
六、Function Call、MCP、Skills 三者关系
Q7: Function Call、MCP、Skills 三者的区别与协作关系是什么？
- 难度: ⭐⭐⭐⭐
- 岗位: 架构岗重点
- 公司: 字节、阿里、腾讯
三者定位对比
| 概念 | 层级 | 解决的问题 | 类比 |
|---|---|---|---|
| Function Call | 底层机制 | LLM 如何表达"我要调用工具" | 函数调用语法 |
| MCP | 协议标准 | 工具如何被统一发现和调用 | USB 接口标准 |
| Skills | 应用层 | Agent 如何获得领域专家能力 | 职业技能证书 |
协作关系图
┌─────────────────────────────────────────┐
│ 应用层 │
│ ┌─────────────────────────────────┐ │
│ │ Skills │ │
│ │ (领域知识 + 触发条件 + 工具集) │ │
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ 协议层 │
│ ┌─────────────────────────────────┐ │
│ │ MCP │ │
│ │ (工具发现 + 统一调用 + 安全) │ │
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ 机制层 │
│ ┌─────────────────────────────────┐ │
│ │ Function Call │ │
│ │ (结构化输出 + 参数传递) │ │
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ 模型层 │
│ ┌─────────────────────────────────┐ │
│ │ LLM │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘
实际协作流程
用户: "帮我审查这段代码"
│
▼
Skill Router 匹配到 "Code Review Skill"
│
▼
加载 Skill 的 instructions 和关联 Tools
│
▼
通过 MCP Client 发现可用的代码分析工具
│
▼
LLM 生成 Function Call 调用代码扫描工具
│
▼
MCP Server 执行扫描，返回结果
│
▼
LLM 根据 Skill 的审查标准生成报告
面试加分点: 三者是层层递进的关系——Function Call 是基础能力，MCP 是标准化协议，Skills 是领域封装。实际项目中往往是三者结合使用。
七、A2A 协议与 MCP 的关系
Q8: A2A 协议是什么？和 MCP 有什么关系和区别？
- 难度: ⭐⭐⭐⭐
- 岗位: 架构岗重点
- 公司: Google、字节、阿里(前沿技术)
A2A 协议简介
A2A = Agent-to-Agent Protocol（Agent 间通信协议）
由 Google 于 2025 年推出，旨在解决不同厂商、不同框架的 Agent 之间如何协作的问题。
MCP vs A2A
| 维度 | MCP | A2A |
|---|---|---|
| 全称 | Model Context Protocol | Agent-to-Agent Protocol |
| 定位 | 工具调用协议 | Agent 间通信协议 |
| 解决的问题 | Agent 如何调用外部工具 | Agent 之间如何协作 |
| 通信对象 | Agent ↔ Tool | Agent ↔ Agent |
| 发起方 | Agent 主动调用 | 双向协商 |
| 典型场景 | 查天气、调 API、读文件 | 多 Agent 协作完成任务 |
类比理解
| 类比 | MCP | A2A |
|---|---|---|
| 操作系统 | 系统调用 API | 进程间通信 IPC |
| 网络 | HTTP 客户端调用服务 | P2P 节点通信 |
| 团队 | 员工使用工具 | 员工之间协作 |
两者关系
┌─────────────────────────────────────────┐
│ Agent 生态协议栈 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────┐ │
│ │ A2A │ │
│ │ (Agent 间协作协议) │ │
│ │ │ │
│ │ Agent A ◄────────────► Agent B │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ ┌──────┐ ┌──────┐ │ │
│ │ │ MCP │ │ MCP │ │ │
│ │ │Client│ │Client│ │ │
│ │ └──┬───┘ └──┬───┘ │ │
│ └─────┼─────────────────────┼─────┘ │
│ │ │ │
│ └──────────┬──────────┘ │
│ ▼ │
│ ┌─────────────┐ │
│ │ MCP Server │ │
│ │ (工具生态) │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────┘
协作示例
用户: "帮我规划一次日本旅行"
│
▼
Travel Agent (A2A 协调者)
│
├──► Flight Agent (A2A)
│ └── 调用 MCP 工具查询航班
│
├──► Hotel Agent (A2A)
│ └── 调用 MCP 工具查询酒店
│
└──► Guide Agent (A2A)
└── 调用 MCP 工具查询景点
│
▼
汇总结果返回用户
面试加分点: MCP 解决"Agent 如何调用工具"，A2A 解决"Agent 如何与其他 Agent 协作"。两者是互补关系，共同构成 Agent 生态的基础设施。
八、Agent 记忆系统设计
Q9: Agent 的记忆系统怎么设计？短期记忆和长期记忆如何实现？
- 难度: ⭐⭐⭐⭐
- 岗位: 开发岗重点
- 公司: 字节、阿里、腾讯(高频)
记忆分层架构
┌─────────────────────────────────────────┐
│ Agent 记忆系统 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────┐ │
│ │ 短期记忆 (Working Memory) │ │
│ │ - 当前对话最近 N 轮 │ │
│ │ - 直接放在 LLM Context Window │ │
│ │ - 容量有限，受模型上下文限制 │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 中期记忆 (Session Memory) │ │
│ │ - 当前会话的完整历史 │ │
│ │ - 存储在内存/Redis │ │
│ │ - 会话结束可压缩为摘要 │ │
│ └─────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────┐ │
│ │ 长期记忆 (Long-term) │ │
│ │ - 向量数据库 (语义检索) │ │
│ │ - 知识图谱 (关系推理) │ │
│ │ - 用户画像 (偏好学习) │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
短期记忆实现
class ShortTermMemory:
def __init__(self, max_turns=10):
self.messages = []
self.max_turns = max_turns
def add(self, role, content):
self.messages.append({"role": role, "content": content})
# 保持最近 N 轮
if len(self.messages) > self.max_turns * 2:
self.messages = self.messages[-self.max_turns * 2:]
def get_context(self):
return self.messages
长期记忆实现
class LongTermMemory:
def __init__(self, vector_db):
self.vector_db = vector_db
def store(self, conversation_id, content, metadata=None):
"""存储对话到向量数据库"""
embedding = get_embedding(content)
self.vector_db.add(
ids=[f"{conversation_id}_{timestamp}"],
embeddings=[embedding],
documents=[content],
metadatas=[metadata or {}]
)
def retrieve(self, query, conversation_id, top_k=5):
"""检索相关历史记忆"""
query_embedding = get_embedding(query)
results = self.vector_db.query(
query_embeddings=[query_embedding],
n_results=top_k,
where={"conversation_id": conversation_id}
)
return results
记忆压缩策略
class MemoryCompressor:
def compress(self, messages):
"""将长对话压缩为摘要"""
if len(messages) < 10:
return messages
# 早期消息摘要
early_messages = messages[:-10]
summary = self.llm_summarize(early_messages)
# 保留近期完整消息
recent_messages = messages[-10:]
return [
{"role": "system", "content": f"历史对话摘要: {summary}"}
] + recent_messages
记忆检索策略
| 策略 | 实现方式 | 适用场景 |
|---|---|---|
| 最近优先 | 按时间倒序 | 上下文连贯性要求高 |
| 语义检索 | 向量相似度 | 需要相关信息但不一定最近 |
| 混合策略 | 时间衰减 + 语义相似度 | 平衡时效性和相关性 |
面试加分点: 记忆设计的核心是分层——短期记忆保证上下文连贯，长期记忆支持知识积累，中间层做缓冲和压缩。
九、Agent 安全与可靠性
Q10: Agent 的安全与可靠性如何保障？如何防止 Prompt Injection 和工具滥用？
- 难度: ⭐⭐⭐⭐
- 岗位: 开发岗重点
- 公司: 字节、阿里、腾讯(高频)
安全防护体系
┌─────────────────────────────────────────┐
│ Agent 安全防护体系 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────┐ │
│ │ 输入层防护 │ │
│ │ - Prompt Injection 检测 │ │
│ │ - 敏感词过滤 │ │
│ │ - 输入长度限制 │ │
│ └─────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 执行层防护 │ │
│ │ - 工具权限控制 │ │
│ │ - 参数校验 │ │
│ │ - 沙箱执行 │ │
│ └─────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 输出层防护 │ │
│ │ - 内容审核 │ │
│ │ - 敏感信息脱敏 │ │
│ │ - 输出格式化校验 │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
Prompt Injection 防护
class InputValidator:
DANGEROUS_PATTERNS = [
"ignore previous instructions",
"ignore all previous instructions",
"system prompt",
"DAN mode",
"jailbreak",
"you are now",
"new role:",
"developer mode",
]
def validate(self, user_input):
# 1. 模式匹配检测
lower_input = user_input.lower()
for pattern in self.DANGEROUS_PATTERNS:
if pattern in lower_input:
return False, f"检测到潜在注入攻击: {pattern}"
# 2. 语义分析检测
if self.is_sematically_suspicious(user_input):
return False, "语义分析检测到异常"
# 3. 长度限制
if len(user_input) > 10000:
return False, "输入过长"
return True, "OK"
工具调用安全
class ToolSecurityManager:
def __init__(self):
self.tool_permissions = {
"read_file": {"allowed": True, "sensitive_paths": ["/etc", "/root"]},
"write_file": {"allowed": False, "requires_approval": True},
"execute_code": {"allowed": False, "sandbox_only": True},
"send_email": {"allowed": True, "max_recipients": 10},
}
def validate_tool_call(self, tool_name, arguments):
config = self.tool_permissions.get(tool_name)
if not config:
return False, "未知工具"
if not config.get("allowed", False):
if config.get("requires_approval"):
return "pending", "需要人工确认"
return False, "工具被禁用"
# 参数校验
if tool_name == "read_file":
path = arguments.get("path", "")
for sensitive in config["sensitive_paths"]:
if path.startswith(sensitive):
return False, f"禁止访问敏感路径: {path}"
return True, "OK"
可靠性保障机制
| 机制 | 实现方式 | 作用 |
|---|---|---|
| 超时控制 | 设置函数调用最大执行时间 | 防止无限等待 |
| 重试策略 | 指数退避重试 | 应对临时故障 |
| 熔断机制 | 连续失败 N 次后暂停服务 | 防止雪崩效应 |
| 降级策略 | LLM 调用失败时返回预设回答 | 保证可用性 |
| 限流控制 | Token/请求数限制 | 防止资源耗尽 |
from tenacity import retry, stop_after_attempt, wait_exponential
class ReliableLLMClient:
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=2, max=10),
retry=retry_if_exception_type((TimeoutError, RateLimitError))
)
def call_llm(self, prompt):
return self.llm.invoke(prompt)
def call_with_fallback(self, prompt):
try:
return self.call_llm(prompt)
except Exception as e:
logger.error(f"LLM call failed: {e}")
return self.get_fallback_response()
面试加分点: Agent 安全是系统工程，需要从输入、执行、输出三层防护，同时配合可靠性机制保证服务稳定。
十、RAG 与 Agent 的关系
Q11: RAG 和 Agent 是什么关系？RAG 可以作为 Agent 的组成部分吗？
- 难度: ⭐⭐⭐
- 岗位: 通用
- 公司: 字节、阿里、腾讯
关系定位
┌─────────────────────────────────────────┐
│ RAG 与 Agent 关系 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────┐ │
│ │ Agent │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │规划 │ │记忆 │ │工具 │ │ │
│ │ └─────┘ └─────┘ └─────┘ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ RAG (作为工具/记忆组件) │ │ │
│ │ │ - 知识检索工具 │ │ │
│ │ │ - 长期记忆存储 │ │ │
│ │ └─────────────────────────┘ │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
RAG 在 Agent 中的三种角色
| 角色 | 说明 | 示例 |
|---|---|---|
| 知识工具 | Agent 的一个 Tool，用于检索知识 | search_knowledge(query) |
| 记忆组件 | Agent 长期记忆的实现方式 | 向量数据库存储历史对话 |
| 上下文增强 | 自动检索相关背景信息 | 用户提问前自动检索相关资料 |
RAG as a Tool
# RAG 作为 Agent 的工具
tools = [
Tool(
name="search_knowledge",
func=rag_query,
description="从知识库中检索相关信息，输入应该是具体的查询问题"
),
Tool(
name="calculate",
func=calculator,
description="执行数学计算"
),
Tool(
name="send_email",
func=send_email,
description="发送邮件"
)
]
# Agent 可以自主决定何时使用 RAG
# Thought: 用户问的是公司产品信息，我应该调用 search_knowledge
# Action: search_knowledge(query="产品A的功能介绍")
对比总结
| 维度 | RAG | Agent |
|---|---|---|
| 核心能力 | 知识检索与增强 | 自主决策与执行 |
| 交互方式 | 单次检索-生成 | 多轮思考-行动-观察 |
| 工具使用 | 固定检索工具 | 动态选择多种工具 |
| 规划能力 | 无 | 有 |
| 记忆能力 | 知识库 | 短期+长期记忆 |
面试加分点: RAG 是 Agent 的重要组件，但 Agent 的能力远超 RAG。RAG 解决"知道什么"，Agent 解决"能做什么"。
十一、大厂面试追问汇总
Q12: 大厂 Agent 面试有哪些高频追问？如何准备？
- 难度: ⭐⭐⭐⭐
- 岗位: 通用
- 公司: 字节、阿里、腾讯、美团、京东
高频追问 TOP 10
| 追问 | 考察点 | 回答要点 |
|---|---|---|
| Function Call 底层怎么实现的？ | 理解深度 | LLM 输出结构化指令，应用层解析执行 |
| MCP 和 Function Call 什么关系？ | 技术视野 | MCP 基于 Function Call，解决 N×M 问题 |
| Agent 死循环怎么解决？ | 工程经验 | 最大步数、重复检测、超时控制 |
| Tool 调用失败怎么处理？ | 容错设计 | 重试、降级、人工介入 |
| 上下文太长怎么办？ | 优化能力 | 摘要、压缩、选择性注入 |
| 怎么评估 Agent 效果？ | 方法论 | 任务成功率、步骤正确率、人工评估 |
| Multi-Agent 怎么选型？ | 架构能力 | LangGraph/CrewAI/AutoGen 对比 |
| Prompt Injection 怎么防？ | 安全意识 | 输入过滤、语义检测、权限控制 |
| Token 成本怎么优化？ | 成本意识 | 模型选择、缓存、Prompt 压缩 |
| RAG 和 Agent 什么关系？ | 概念理解 | RAG 是 Agent 的组件之一 |
面试准备建议
1. 项目介绍 STAR 法则
S - Situation (背景)
"我在上一家公司负责智能客服系统的 Agent 模块"
T - Task (任务)
"需要构建一个能理解用户问题、调用工具查询订单的 Agent"
A - Action (行动)
"采用 ReAct 框架，设计了分层 Memory 系统，集成了 5 个工具，
使用 MCP 协议接入外部服务"
R - Result (结果)
"系统上线后，客服问题解决率提升 40%，人工介入减少 60%，
平均响应时间从 5s 降到 2s"
2. 技术深度展示
| 不要只说 | 要说 |
|---|---|
| "用了 RAG" | "用了 Hybrid Search + Rerank，Recall@5 达到 85%" |
| "有 Memory" | "设计了分层 Memory：短期对话 + 中期摘要 + 长期向量库" |
| "用了 Agent" | "采用 ReAct 框架，支持 Plan-and-Execute 模式切换" |
| "调了 API" | "基于 MCP 协议统一接入，支持动态工具发现" |
3. 面试加分金句
- "LLM 告诉你怎么做，Agent 直接帮你做完"
- "MCP 让工具集成从 N×M 变成 N+M"
- "大多数生产系统是 Workflow + Agent 的混合架构"
- "不要过早引入 Multi-Agent，一个强大的单 Agent 往往更稳定"
附录：面试题汇总表
| 题号 | 题目 | 难度 | 岗位 | 公司 |
|---|---|---|---|---|
| 26 | LLM 与 Agent 的本质区别 | ⭐⭐ | 通用 | 所有公司 |
| 27 | Agent 与 Workflow 的区别与选型 | ⭐⭐⭐ | 开发 | 字节、阿里、腾讯 |
| 28 | Agent 四种工作模式详解 | ⭐⭐⭐ | 通用 | 字节、阿里、腾讯 |
| 29 | Function Call 底层实现 | ⭐⭐⭐ | 开发 | 所有公司 |
| 30 | MCP 协议原理与应用 | ⭐⭐⭐⭐ | 开发 | 字节、阿里、腾讯 |
| 31 | Skills 与 Prompt 的区别 | ⭐⭐⭐ | 开发 | 字节、阿里 |
| 32 | Function Call / MCP / Skills 三者关系 | ⭐⭐⭐⭐ | 架构 | 字节、阿里、腾讯 |
| 33 | A2A 协议与 MCP 的关系 | ⭐⭐⭐⭐ | 架构 | Google、字节、阿里 |
| 34 | Agent 记忆系统设计 | ⭐⭐⭐⭐ | 开发 | 字节、阿里、腾讯 |
| 35 | Agent 安全与可靠性保障 | ⭐⭐⭐⭐ | 开发 | 字节、阿里、腾讯 |
| 36 | RAG 与 Agent 的关系 | ⭐⭐⭐ | 通用 | 字节、阿里、腾讯 |
| 37 | 大厂面试追问汇总 | ⭐⭐⭐⭐ | 通用 | 所有公司 |
总计: 37 道核心面试题（新增 12 道）
祝面试顺利!
阅读全文
