Agent项目：电商智能客服问答助手Agent
项目简介
本项目是一个企业级多Agent智能客服系统，模拟真实金融/电商公司的客服场景。系统由多个专业AI Agent协同工作，自动处理用户咨询、工单创建、知识检索等任务。
核心功能
Supervisor 编排模式
什么是Supervisor？ 就像一个项目经理，接到需求后分配给不同专家处理，最后汇总结果。
53%
47%
分层记忆系统
为什么需要三层记忆？ 类似人类记忆：工作桌(工作记忆) + 笔记本(短期) + 大脑长期记忆。
#ZVyQbIvlBRNt text { white-space: pre; }#ZVyQbIvlBRNt .fb0 { stroke: var(--N900-FG, 0.15); }#ZVyQbIvlBRNt .fb0 {stroke: rgba(31,35,41, 0.15)}#ZVyQbIvlBRNt .fx0 { stroke-miterlimit: 10; }#ZVyQbIvlBRNt .fx0 {stroke-miterlimit: 10}#ZVyQbIvlBRNt .fa1 { fill: rgb(187, 191, 196); }#ZVyQbIvlBRNt .fa1 {fill: rgb(187, 191, 196)}#ZVyQbIvlBRNt .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#ZVyQbIvlBRNt .fx1 {font-style: normal}#ZVyQbIvlBRNt .fx2 { text-anchor: middle; }#ZVyQbIvlBRNt .fx2 {text-anchor: middle}#ZVyQbIvlBRNt .fx3 { dominant-baseline: central; }#ZVyQbIvlBRNt .fx3 {dominant-baseline: central}#ZVyQbIvlBRNt .fx4 { stroke: none; }#ZVyQbIvlBRNt .fx4 {stroke: none}#ZVyQbIvlBRNt .fc0 { fill: var(--text-caption); }#ZVyQbIvlBRNt .fc0 {fill: #646a73}#ZVyQbIvlBRNt .fa2 { fill: var(--text-link-disabled); }#ZVyQbIvlBRNt .fa2 {fill: rgb(187, 191, 196)}#ZVyQbIvlBRNt .fa3 { fill: rgb(250, 241, 209); }#ZVyQbIvlBRNt .fa3 {fill: rgb(250, 241, 209)}#ZVyQbIvlBRNt .fx5 { font: 700 16px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#ZVyQbIvlBRNt .fx5 {font-style: normal}#ZVyQbIvlBRNt .fx6 { text-anchor: start; }#ZVyQbIvlBRNt .fx6 {text-anchor: start}#ZVyQbIvlBRNt .fx7 { dominant-baseline: alphabetic; }#ZVyQbIvlBRNt .fx7 {dominant-baseline: alphabetic}#ZVyQbIvlBRNt .fc1 { fill: rgb(31, 35, 41); }#ZVyQbIvlBRNt .fc1 {fill: rgb(31, 35, 41)}#ZVyQbIvlBRNt .fx8 { font: 400 13px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#ZVyQbIvlBRNt .fx8 {font-style: normal}#ZVyQbIvlBRNt .fc2 { fill: rgb(0, 0, 0); }#ZVyQbIvlBRNt .fc2 {fill: rgb(0, 0, 0)}#ZVyQbIvlBRNt .fb1 { fill: var(--N900-FG, 0.15); }#ZVyQbIvlBRNt .fb1 {fill: rgba(31,35,41, 0.15)}#ZVyQbIvlBRNt .fb2 { fill: rgb(209, 217, 224); }#ZVyQbIvlBRNt .fb2 {fill: rgb(209, 217, 224)}#ZVyQbIvlBRNt .fa4 { fill: var(--bg-body); }#ZVyQbIvlBRNt .fa4 {fill: #fff}ABCDE1234记忆层存储位置生命周期延迟用途工作记忆短期记忆长期记忆进程内存 (dict)RedisFAISS/Milvus 向量库单次请求TTL 30分钟永久<1ms1-5ms10-50ms当前推理状态、路由决策上下文多轮对话上下文（保留最近20轮）知识库、用户画像、历史工单
MCP 工具协议
什么是MCP？ Model Context Protocol，AI模型调用外部工具的标准协议，类似HTTP规范了Web通信。
代码块
JSON
{
"name": "order_query",
"description": "查询订单信息",
"inputSchema": {
"type": "object",
"properties": {
"order_id": {"type": "string", "description": "订单ID"}
},
"required": ["order_id"]
}
}
已实现的MCP工具：
•
order_query — 查询订单状态、物流信息
•
ticket_create / ticket_update — 工单创建和更新
•
risk_check — 金融风控接口
•
kb_search — 知识库全文搜索
•
user_profile — 用户画像查询
RAG 知识检索
什么是RAG？ Retrieval-Augmented Generation，先从知识库检索相关内容，再让AI生成回答，避免AI"瞎编"。
代码块
Plain Text
用户问题: "怎么退款？"
↓ Query改写（扩展关键词）
"退款 政策 申请 流程 时限"
↓ 向量化（转为1536维数字）
↓ 向量检索（找最相似的Top-5文档）
↓ 重排序（LLM评估相关性 → Top-3）
↓ 上下文注入（文档内容 + 用户问题）
↓ LLM生成（基于文档的准确回答）
最终回答 + 引用来源标注
全链路追踪 (OpenTelemetry)
可以清楚地看到每次请求经过哪些Agent、每个步骤耗时多少、消耗了多少Token：
代码块
Plain Text
[Root] user_request (总耗时: 2.8s, 总Token: 1850)
├── [Span] supervisor.route_decision → 800ms, 150 tokens
├── [Span] knowledge_rag.process → 1.9s
│ ├── rag.query_rewrite → 200ms
│ ├── rag.vector_search → 15ms
│ ├── rag.rerank → 500ms
│ └── rag.generate_answer → 1200ms, 1200 tokens
├── [Span] compliance_checker.process → 600ms, 400 tokens
└── [Span] supervisor.synthesize → 50ms
合规审查
专为金融场景设计：
•
敏感词检测：自动识别违规词汇
•
PII保护：过滤身份证、银行卡等隐私信息
•
越权访问治理：防止用户绕过权限限制
•
双重审查：规则引擎（快，<2ms）+ LLM审查（准，~600ms）
系统架构
整体架构图
代码块
Plain Text
70%
30%
请求处理流程
代码块
Plain Text
① 用户发送消息："我的订单什么时候到？"
↓
② Supervisor 分析意图 → 路由决策
↓
③ 意图路由 Agent 识别意图: "order_query"
↓
④ 知识检索 Agent → 调用MCP工具查询订单
↓
⑤ 合规审查 Agent → 检查回复内容合规性
↓
⑥ Supervisor 汇总结果 → 返回最终回复
快速开始
前置条件
•
一个 OpenAI API Key（或其他LLM的Key）
•
Docker（可选，用于一键启动）
方式一：Docker 一键启动（推荐新手）
代码块
Markdown
# 1. 克隆项目
git clone https://github.com/bcefghj/smart-cs-multi-agent.git
cd smart-cs-multi-agent
# 2. 配置API Key
cp python-impl/.env.example python-impl/.env
# 编辑 .env 文件，填入你的 OPENAI_API_KEY
方式二：Python 版本（直接运行）
代码块
Markdown
# 进入Python实现目录
cd python-impl
# 安装依赖
pip install -r requirements.txt
# 配置环境变量
cp .env.example .env
# 编辑 .env，至少填写：
📁 项目结构
代码块
Plain Text
smart-cs-multi-agent/
│
├── 📄 README.md ← 你现在看的这个文件
💻 核心代码解析
Supervisor 编排核心逻辑（Python）
这是整个系统最重要的部分，理解了这个代码，面试时就能讲清楚多Agent协作原理：
代码块
Python
# python-impl/agents/supervisor.py
# 1. 定义全局状态（类似"黑板"，所有Agent共享）
class AgentState(TypedDict):
messages: list[BaseMessage] # 对话历史
user_id: str # 用户ID
intent: str # 识别到的意图
sub_results: dict[str, Any] # 各Agent处理结果
compliance_passed: bool # 合规是否通过
final_response: str # 最终回复
# 2. 构建有向图（定义Agent之间的流转关系）
面试时怎么讲这段代码？
"我们用LangGraph的StateGraph构建了一个有向图，Supervisor作为中心节点负责路由，子Agent各司其职。所有回复都强制经过合规审查节点，这是金融场景的合规要求。MemorySaver提供检查点功能，支持对话断点续接。"
MCP工具协议实现
代码块
Python
# python-impl/mcp/tools.py
# MCP工具的核心：描述工具能力，让AI知道什么时候用这个工具
order_query_tool = {
"name": "order_query",
"description": "查询用户订单的状态、物流、金额等信息",
"inputSchema": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "订单编号，如 ORD-2024-001"
},
"user_id": {
"type": "string",
"description": "用户ID，用于权限验证"
}
},
"required": ["order_id", "user_id"]
代码讲解文档 — 核心模块逐行解析
本文档对三语言实现的核心模块进行详细讲解，帮助你在面试中清晰地描述代码设计。
Python实现核心讲解
1.1 Supervisor编排 (supervisor.py)
代码块
Python
class AgentState(TypedDict):
💡
设计要点：
•
Annotated[list[BaseMessage], add_messages]：LangGraph的reducer机制。当多个节点向messages写入时，add_messages会自动追加而非覆盖
•
sub_results是一个dict：各Agent把结果写入不同key，避免互相覆盖
•
compliance_passed是布尔值：合规审查的结果，决定最终是否返回自动回复
Graph构建 — 编排的核心
代码块
Python
graph = StateGraph(AgentState)
# 添加节点（每个节点是一个异步函数）
graph.add_node("supervisor_route", supervisor.route_decision)
graph.add_node("knowledge_rag", knowledge_agent.process)
graph.add_node("ticket_handler", ticket_agent.process)
graph.add_node("compliance_check", compliance_agent.process)
graph.add_node("synthesize", supervisor.synthesize_response)
# 设置入口
graph.set_entry_point("supervisor_route")
# 条件边：根据意图路由到不同Agent
graph.add_conditional_edges(
"supervisor_route",
🔎
设计模式：
•
条件路由：add_conditional_edges根据运行时状态决定走哪条路径
•
汇聚点：compliance_check是汇聚节点，确保所有回复都经过审查
•
Checkpoint：MemorySaver()保存每步的State快照，支持断点恢复
1.2 RAG知识检索 (knowledge_rag.py)
完整RAG流程
代码块
Python
async def process(self, state):
original_query = messages[-1].content
# Step 1: Query改写（口语 → 检索友好）
rewritten_query = await self.rewrite_query(original_query)
# Step 2: 向量检索（Top-5）
raw_docs = await self.retrieve_documents(rewritten_query, top_k=5)
🧠
为什么先检索Top-5再排序到Top-3？
•
向量检索是近似检索，Top-5保证召回率
•
重排序用LLM做更精确的相关性判断，从5筛到3提升精确率
•
最终只注入3篇文档，控制Token消耗
1.3 合规审查 (compliance_checker.py)
两阶段审查机制
代码块
Python
async def full_check(self, content: str) -> ComplianceResult:
# Phase 1: 规则引擎（毫秒级，零成本）
rule_result = await self.rule_check(content)
# 高风险直接拦截，不走LLM
if not rule_result.passed and rule_result.risk_level in ("high", "critical"):
return rule_result
# Phase 2: LLM深度审查（秒级，有API成本）
llm_result = await self.llm_check(content)
# 合并两阶段结果
all_violations = rule_result.violations + llm_result.violations
final_passed = rule_result.passed and llm_result.passed
👉
设计要点：
•
规则引擎是高召回率的快筛：宁可多报不能漏报
•
LLM审查是高精确率的精筛：处理规则覆盖不了的场景
•
高风险直接拦截不走LLM：既省成本又降延迟
1.4 MCP工具协议 (mcp_server.py)
工具注册（装饰器模式）
代码块
Python
@server.register(
name="order_query",
description="查询订单信息",
input_schema={...},
category="order",
JSON-RPC 2.0处理
代码块
Python
async def handle_jsonrpc(self, request: dict) -> dict:
method = request.get("method", "")
if method == "tools/list": # 工具发现
result = self.list_tools()
elif method == "tools/call": # 工具调用
result = await self.call_tool(name, arguments)
📢
符合MCP规范的关键点：
1.5 OpenTelemetry追踪 (otel_config.py)
追踪装饰器
代码块
Python
def trace_agent_call(agent_name: str) -> Callable:
def decorator(func):
async def wrapper(*args, **kwargs):
with tracer.start_as_current_span(span_name) as span:
span.set_attribute("agent.name", agent_name)
设计模式：装饰器模式 + AOP（面向切面编程）。业务代码完全不需要关心追踪逻辑，只需要加一行装饰器。
部署指南
本地开发环境
Python版本
代码块
Bash
cd python-impl
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env
# 编辑 .env 填入你的API Key
python -m api.main
访问: http://localhost:8000/docs (Swagger UI)
Docker部署
单服务启动
代码块
Markdown
# Python
Docker Compose 一键启动
代码块
Plain Text
docker-compose up -d
API接口说明
所有三个版本提供统一的REST API：
POST /api/chat — 聊天接口
代码块
JSON
// Request
{
"message": "我想了解一下理财产品A",
"user_id": "user_001",
"session_id": "optional-session-id"
}
// Response
{
"response": "关于理财产品A...",
"session_id": "xxx",
"intent": "knowledge_rag",
"compliance_passed": true
}
GET /api/history/{session_id} — 对话历史
GET /api/tools — MCP工具列表
GET /api/metrics — 系统指标
GET /health — 健康检查
环境变量说明
📚面试准备材料
配套完整面试资料，帮你从"能看懂代码"到"面试时能流畅讲清楚"：
简历项目经历模板 — 智能客服多Agent系统
担任角色： AI 产品经理 项目描述： 针对传统单体大模型客服在面对复杂业务时易出现幻觉、逻辑混乱及合规风险等痛点，从 0 到 1 主导设计基于 Supervisor 架构的企业级多智能体协同客服系统。通过意图路由分发与专业 Agent 协作，实现从“被动问答”到“主动解决工单”的业务闭环。
核心职责与产出：
•
构建 Supervisor 多智能体编排架构： 弃用单点 Prompt，设计“总控调度 (Supervisor) + 专业节点 (知识检索、工单处理)”的分层架构。定义了统一的 AgentState 状态空间，实现上下文的无缝传递与复杂多轮对话的准确路由。
•
设计混合 RAG 与 MCP 工具链路： 规划知识检索中枢，设计“稠密+稀疏”混合检索及大模型重排 (Re-ranking) 策略，保障高召回与高精度。引入 MCP（模型上下文协议），标准化打通订单查询、金融风控、工单 CRUD 等内部系统 API，赋予 Agent 真实业务执行力。
•
搭建金融级合规与安全防线 (Compliance Agent)： 在架构末端设计独立的“汇聚点”审查节点。制定“规则引擎拦截（毫秒级） + LLM 语义审查”的双重风控策略，有效过滤敏感词、拦截 PII (个人隐私) 泄露及越权访问，确保输出 100% 合规。
•
全链路数据评估与迭代机制建设： 推进接入全链路追踪系统，精细化监控各 Agent 节点的响应耗时、路由准确率及 Token 消耗规模。构建基于 Bad Case 的归因排查 SOP，为 Prompt 调优和模型迭代提供数据支撑。
项目业绩（可根据你的实际情况微调数字）：
•
将复杂业务（如退改签+政策咨询）的首问解决率提升了 XX%。
•
通过重排策略和严格的合规汇聚节点，将大模型幻觉率和业务违规率降至 0。
•
通过全链路 Token 追踪与上下文按需注入，将单次对话综合推理成本降低了 40%。
STAR面试话术 — 智能客服多Agent系统
请介绍一下你最有挑战的项目
【解题思路】突出业务痛点之深，以及你作为 PM 引入 AI 带来的重构价值。
S (情境)： 我最有挑战的项目是从 0 到 1 规划并落地的“智能客服多 Agent 协同系统”。当时我们的痛点是，传统的单体大模型客服在处理复杂场景（比如同时包含“查订单”和“退款政策”的诉求）时，很容易出现逻辑混乱和幻觉，而且金融/电商场景对合规的要求是零容忍的。
T (任务)： 我的任务是设计一套既能处理复杂多意图并发，又能保证 100% 输出合规的高可用 AI 客服架构。
A (行动)： 挑战在于如何解耦复杂的逻辑。我没有采用传统的长 Prompt 堆砌，而是主导设计了 Supervisor（总控调度）多智能体架构。我把系统拆分为意图路由、混合检索（RAG）、工单执行和合规审查四个独立的 Agent。同时，我重新定义了各个节点间的上下文传递机制，确保信息不丢失。
R (结果)： 项目上线后，我们将复杂工单的首问解决率提升了 XX%，最关键的是，通过架构上的物理隔离，大模型幻觉导致的业务违规率降到了 0。这个项目让我真正跑通了 AI 产品从“被动对话”到“主动执行”的业务闭环。
你在项目中遇到过什么技术难题？怎么解决的？
【解题思路】AI PM 的“技术难题”通常是：幻觉控制、Token 成本、响应延迟、Agent 死循环。结合你学过的设计模式来回答。
S (情境)： 在项目初期，我们遇到了 Agent 极易陷入“死循环”和响应延迟过高的难题。
T (任务)： 当时我们为了让模型自主解决问题，默认使用了基础的 ReAct 模式（思考-行动-观察）。但在处理多步骤的订单核查时，模型经常会在“调用工具”和“观察”之间反复横跳，导致单次回复耗时超过 10 秒，Token 成本也严重超标。
A (行动)： 针对这个难题，我协同算法和研发团队做了两步产品策略上的调整。第一，改变 Agent 的设计模式。对于标准化的 SOP 流程，我们将 ReAct 降级为 Plan and Solve（计划与解决） 配合 ReWOO 模式，让模型先全局规划并并行调用工具，切断它盲目试错的路径。第二，引入防呆机制与自我纠错。我优化了 System Prompt，加入了 Basic Reflection（基础反思） 逻辑，强制规定“如果同一工具调用 3 次失败，必须跳出循环并呼叫人工”。
R (结果)： 这套组合拳打下来，我们在保证准确率的前提下，将端到端的平均响应延迟降低了近一半，同时综合推理成本（Token 消耗）下降了 XX%。
为什么选择这个技术栈？有没有考虑过替代方案？
【解题思路】这里的“技术栈”指的是“产品架构选型”（多 Agent vs 单 Agent；不同 Agent 模式的权衡）。体现你的商业思维和技术审美。
S & T (情境与任务)： 在立项之初，关于如何构建这个中枢大脑，我们需要在架构选型上做决策。
A (行动)： 我们当时的替代方案是最简单直接的：单体大模型 + 超长 Prompt + RAG。这种方案开发快、前期投入低。但我最终力排众议选择了 Supervisor 多 Agent 编排架构。 选择的原因有三点： 第一，扩展性。随着业务增长，单体 Prompt 会越来越臃肿，牵一发而动全身；而多 Agent 架构下，新增一个“发票处理 Agent”就像挂载一个新插件一样简单。 第二，控制力。大模型的输出是概率性的，为了兜底，我们在架构末端接了一个纯规则+语义双重校验的 Compliance Agent（合规审查节点），单体模型很难做到这种硬性的流程拦截。 第三，ROI 考量。我们也评估过像 LATS（树搜索） 这种极度消耗算力的极致推理模式，但考虑到客服场景并发量大，用户的等待耐心有限，我们最终选择了性价比更高的混合路由调度，把好钢（昂贵的模型）用在刀刃（复杂意图拆解）上。
R (结果)： 事实证明这个架构选型是非常具有前瞻性的，后期业务扩展新场景时，我们的架构完全接得住，开发成本极低。
项目中你是怎么保证系统质量的？
【解题思路】传统软件靠 QA 测试，AI 软件靠 Eval (评估体系) 和 Bad Case 驱动。
S & T (情境与任务)： 传统的软件测试是测确定性的 Bug，但 AI 系统的输出每次都不一样。因此，如何保证一个概率性系统的交付质量，是我作为 PM 必须要抓的核心。
A (行动)： 我从三个维度构建了 AI 的质量保障体系（Eval 体系）：
构建黄金数据集 (Golden Dataset)： 上线前，我从真实历史客诉中清洗出几百条最具代表性的极度复杂 Case，作为自动化测试的基准库，每次迭代必须跑通这些 Case 才能发版。
建立 Bad Case 归因 SOP： 遇到用户点踩或回答错误时，我要求团队必须定位到具体环节——是 RAG 阶段没有召回知识（检索问题）？还是 Supervisor 路由分发错了（意图识别问题）？或者是最终 Agent 的推理逻辑崩了（Prompt 问题）？坚决拒绝“玄学调优”。
引入 MCP 协议规范接口： 为了保证大模型调用内部业务接口的稳定性，我们引入了模型上下文协议 (MCP)，把所有工具的输入输出标准化，极大降低了模型传参错误的概率。
R (结果)： 这套流程让我们的系统质量从“盲盒”变成了“白盒”，每次迭代都有清晰的数据支撑，系统的鲁棒性得到了质的飞跃。
八股文题库 — 多Agent系统 & RAG & 大模型应用
第一部分：多 Agent 架构与编排 (Architecture)
基础：什么是 Supervisor（总控）架构？为什么在这个项目中采用它？
•
回答：Supervisor 类似于“项目经理”，负责接收用户意图并分发给专业子 Agent。采用它是为了解决单 Agent 处理复杂任务时意图漂移的问题。通过解耦，每个子 Agent 专注于特定领域（如订单或知识库），系统更易于扩展和调试。
基础：Agent 之间的“状态（State）”是如何传递的？
•
回答：系统维护一个全局 State 对象，包含历史对话、当前提取的变量（如订单号）和下一步路由建议。每个 Agent 执行完后更新 State，由 Supervisor 根据更新后的 State 决定终止还是流转。
中阶：ReAct 模式在客服场景中的风险是什么？如何规避？
•
回答：风险是模型容易在“思考-行动”循环中陷入死循环或产生幻觉。规避策略是限制最大迭代次数，并对标准业务流程采用 Plan and Solve 模式，由 PM 预设好执行步骤，减少模型的随机性。
中阶：如何处理跨领域的复杂意图（例如用户同时问订单状态和退款政策）？
•
回答：Supervisor 会先进行意图拆解。逻辑上可以设计为“串行处理”，先由订单 Agent 查询，将结果存入上下文，再由知识库 Agent 结合订单信息回答退款政策。
中阶：多 Agent 系统中，如何保证上下文（Context）不超出 Token 限制？
•
回答：采用“按需注入”策略。只有当前被激活的子 Agent 相关背景和最近 3-5 轮核心对话会被送入 LLM，历史长文本知识通过 RAG 压缩成摘要后存入 State，避免全量堆砌。
进阶：如果 Agent 架构变得非常复杂，你如何防止死循环？
•
回答：在产品逻辑上设置“哨兵机制”。记录每个节点在单次会话中的触发频率，一旦超过阈值（如 3 次），强制触发强制拦截并转接人工，同时记录该 Case 用于后期归因。
进阶：你是如何定义子 Agent 的颗粒度的？
•
回答：基于“职责单一性”和“工具复用性”。如果一个任务需要独立的工具集（如数据库访问）和特定的合规约束（如支付安全），它就应该是一个独立 Agent。
进阶：多 Agent 并行执行时，如何处理结果冲突？
•
回答：通过设计一个“汇聚节点（Aggregator）”。该节点不执行任务，只负责接收多个子 Agent 的输出，根据预设的优先级（如：合规 Agent 权限最高）进行冲突检测和最终结果润色。
第二部分：RAG 与知识管理 (RAG & Data)
基础：为什么在这个项目中需要 RAG，而不是把知识写在 Prompt 里？
•
回答：因为知识库（如数千页的业务手册）超出了 Prompt 窗口，且 RAG 能保证回答来源于实时、确定的事实，有效降低模型幻觉，降低 Token 成本。
基础：你是如何进行文档切分（Chunking）的？
•
回答：采用“语义化切分”。不是简单按字符数，而是基于文档的标题层级（Markdown 结构）进行拆分，并保留一定的重叠（Overlap），确保段落间的上下文衔接。
中阶：什么是混合检索（Hybrid Search）？优势是什么？
•
回答：结合了关键词搜索（精确匹配，如产品型号）和向量检索（语义匹配，如用户抱怨）。优势是既能处理专业术语，也能理解口语化的表达。
中阶：如何评价 RAG 的检索质量？
•
回答：关注“召回率（Recall）”和“准确率（Precision）”。我会看 Top 3 检索出来的片段是否包含正确答案，以及是否有无关噪声干扰了模型判断。
进阶：为什么要在检索后加一个重排（Re-ranking）环节？
•
回答：向量检索通过距离计算，有时会把语义相近但逻辑无关的内容排在前面。重排模型能以更高的算力对 Top 10 结果进行深度匹配，确保送入大模型的一定是最相关的。
进阶：如果知识库里有冲突的信息，产品逻辑怎么处理？
•
回答：在元数据中加入“版本”或“时效性”标签。检索时优先调用最新日期的文档；若日期相同，则由 LLM 在 Prompt 中被告知“存在多种政策，请向用户进一步核实具体情况”。
进阶：如何处理非结构化数据（如 PDF 里的表格）？
•
回答：采用 OCR 配合解析工具将表格转化为 Markdown 或 JSON 格式存储。针对复杂表格，我会设计专用的“表格解析 Agent”来处理特定的行列查询。
进阶：RAG 系统中，用户反馈“搜不到”和“搜错了”哪个更严重？怎么改？
•
回答：都严重。搜不到通常是 Embedding 召回问题，需优化切分逻辑；搜错了是重排或 Prompt 过滤问题。我会通过 Bad Case 驱动，针对性调整权重。
第三部分：工具调用与工程落地 (Tools & Implementation)
基础：什么是 MCP（模型上下文协议）？它对产品迭代有什么好处？
•
回答：它是一种标准化的接口协议。好处是 Agent 只需要对接一套标准协议，就能调用不同系统的 API，极大降低了产品在接入新业务工具时的研发沟通成本。
基础：Agent 调用 API 报错时，你会设计怎样的用户提示？
•
回答：避免显示技术代码。我会设计为“抱歉，系统暂时无法获取您的订单状态，请稍后再试”，并在后台触发自动重试或错误日志记录。
中阶：如何保证 Agent 调用工具时的安全性（如误删订单）？
•
回答：在产品设计上加入“人机协作（HITL）”。对于敏感操作，Agent 只能生成“待执行工单”，必须由用户或后台人工在界面上点击“确认”后方可执行。
中阶：在大模型输出慢（Latency 高）的情况下，如何优化产品体验？
•
回答：采用“流式输出（Streaming）”展现思考过程；设计“进度暗示”，如显示“正在查询数据库...”；或者对高频问题采用缓存策略。
进阶：如何平衡不同模型（如 GPT-4o 和本地模型）的使用？
•
回答：采用“路由降级策略”。简单的意图识别和分类交给轻量级模型；复杂的逻辑推理、长文本总结和最终合规审查交给高性能大模型，以此优化整体 ROI。
进阶：如何监控 Agent 在生产环境中的 Token 消耗？
•
回答：建立“会话看板”，记录每个意图下的平均 Token 消耗。一旦发现某个 Agent 消耗异常，立刻排查是否出现了 Prompt 指令理解偏差导致的无效推理。
进阶：工具调用中，模型总是传错参数怎么办？
•
回答：在 Prompt 中提供 Few-shot（少样本示例），并强制要求模型输出 JSON 格式。同时，在代码层增加一层 Pydantic 或 JSON Schema 校验，格式不对直接打回重生成。
第四部分：评估与业务价值 (Evaluation & Business)
基础：AI 系统的成功指标有哪些？
•
回答：首问解决率（FCR）、人工转接率、端到端响应时间、以及基于 LLM-as-a-Judge 的答案准确分（如 1-5 分）。
基础：什么是“黄金数据集（Golden Dataset）”？
•
回答：由 PM 和业务专家人工标注的、包含典型问题与标准答案的基准测试集，用于在模型更新或 Prompt 修改后进行回归测试。
中阶：如果用户投诉 AI 客服说话“阴阳怪气”，你如何排查？
•
回答：排查 System Prompt 中的 Persona（人格设定）描述，以及 RAG 检索出的参考内容是否包含负面情绪。通过调整 Prompt 词汇约束或引入“语气审查 Agent”来解决。
中阶：如何设计“合规审查节点（Compliance Agent）”的判别逻辑？
•
回答：它不负责回答，只负责审查。逻辑是：输入 = 原始问题 + Agent 生成的回答；输出 = 风险评级 + 拦截原因。我会根据法律法规和公司政策更新其审查准则。
进阶：在没有真实用户数据的情况下，如何进行冷启动测试？
•
回答：使用“模拟器”方法。利用另一个 LLM 扮演具有不同性格和需求的用户，与我的 Agent 系统进行多轮对话，通过这种“红蓝对抗”快速发现架构缺陷。
进阶：如何证明你的多 Agent 系统比传统机器人省钱？
•
回答：对比单位工单处理成本。多 Agent 能够精准识别意图，避免了用户在错误路径上的无效沟通，缩短了对话轮数，且通过意图路由使用低成本模型，整体 Token 费用更低。
进阶：你认为未来 AI 客服的最终形态是什么？
•
回答：从“对话式”转向“任务式”。Agent 不再只是回答问题，而是作为一个具备权限的数字化员工，能感知用户情绪并自主完成复杂的端到端业务处理，实现真正的“无人值守”。
项目深度追问
Q1: "你的 Supervisor 编排和简单的 if-else 路由有什么区别？"
回答： 区别在于“意图的模糊处理能力”和“动态纠错能力”。
•
if-else： 是确定性的硬编码。如果用户没说出关键词，路由就会失效；且它无法处理“上下文相关的意图”。
•
Supervisor： 是语义化的动态调度。它能理解用户在多轮对话中隐含的意图。更重要的是，它具备闭环能力：如果子 Agent 返回的结果不符合预期，Supervisor 可以决定是让它重新执行，还是切换到另一个 Agent，这种“容错性”是 if-else 逻辑无法实现的。
Q2: "分层记忆的三层是怎么协作的？给个具体例子。"
回答： 我们将记忆分为：短期工作记忆（Short-term）、长期用户画像（Long-term）和语义索引摘要（Semantic/Buffer）。
•
例子： 用户问“我上个月买的那个电脑，退货进度到哪了？”
a.
短期记忆：锁定“那个电脑”指的是 1 分钟前对话里提到的订单号 A123。
•
协作逻辑： 这种设计避免了将所有原始对话塞进 Token，通过摘要和标签，我们在保证 Agent “有记性”的同时，极大地节省了成本。
Q3: "合规审查 Agent 的误判率怎么控制？"
回答： 这是个“召回率（Recall）优先”的场景，宁可误杀不能漏过。
双层过滤： 第一层用高性能的敏感词库/正则表达式做硬拦截（毫秒级）；第二层由小型合规模型做语义判定。
置信度阈值： 我们设定了置信度分数。如果模型判定风险在 0.6-0.8 之间（模糊地带），系统会自动将结果标记为“待审核”并推给人工，而不是直接拦截或放行。
负样本迭代： 我们每周会把被人工纠正的“误判 Case”喂回给合规 Agent 做 Few-shot 学习，持续收敛判定标准。
Q4: "如果一个 Agent 超时了，Supervisor 怎么处理？"
回答： 这涉及“优雅降级”的产品设计：
状态监控： Supervisor 设置了单节点 Time-out 超时（如 8 秒）。
策略切换： 如果子 Agent 超时，Supervisor 会启动“兜底逻辑”，比如由总控模型直接根据现有的 RAG 知识库给出一个通用回答，并告知用户“详细信息正在调取中”。
熔断机制： 如果某个 API 持续超时，系统会触发熔断，自动转接人工或引导用户留下联系方式，防止系统整体挂起。
Q5: "RAG 检索的准确率怎么评估？"
回答： 我们采用行业标准的 RAGAS 框架，从四个维度进行“模型打分（LLM-as-a-Judge）”：
•
忠实度 (Faithfulness)：回答是否完全来自检索到的片段？
•
相关性 (Relevance)：回答是否真的解决了用户的问题？
•
检索准确率 (Context Precision)：检索出来的 Top 3 内容里，有用的信息占多少？
•
检索召回率 (Context Recall)：标准答案所需的知识点，检索出来的全不全？ 通过这四个指标，我们能一眼看出是“知识库不行”还是“模型总结不行”。
Q6: "你们怎么处理用户的 Prompt 注入攻击？"
回答： 我们建立了一套“三道防火墙”体系：
输入清洗： 在进入 Agent 之前，由专门的轻量级防火墙模型扫描用户输入，检测是否存在“忽略之前所有指令”等典型注入特征。
角色隔离： 在 System Prompt 中严禁 Agent 接触系统核心配置信息。
输出校验： Agent 的输出必须经过合规 Agent 审计，如果输出内容包含系统指令、代码块或敏感配置，直接拦截。
Q7: "为什么用 LangGraph 而不是 CrewAI？"
回答： 核心考点在于“控制力”。
•
CrewAI： 比较适合“角色扮演”类任务，它的 Agent 行为比较发散，像是个黑盒，很难在复杂的金融/客服流程中精准控制每一步。
•
LangGraph： 它的核心是 DAG（有向无环图）和循环图。作为 PM，我需要系统有极强的确定性。LangGraph 允许我们精准定义状态流转、强行插入人工干预点，且具备天然的“状态持久化”能力，这在企业级应用中是必须的。
Q9: "Token 消耗降低 40% 是怎么做到的？"
回答： 我们主要做了三件事：
意图路由分级： 将 60% 的简单咨询（如查运费、查工号）通过路由分发给 GPT-4o-mini 或国产轻量级模型，只有 40% 的复杂推理才动用 GPT-4o。
动态上下文裁剪： 我们弃用了全量对话透传，而是由摘要 Agent 将超过 5 轮的对话压缩成 200 字以内的语义摘要。
语义缓存（Semantic Cache）： 针对高频重复问题，系统先在向量数据库中进行语义匹配，如果匹配度 >0.95，直接返回缓存结果，不调用 LLM。
Q10: "系统上线后遇到过什么线上事故？"
回答： （STAR 话术示例）：
•
S (情境)： 上线初期，一个促销活动期间，系统出现了“Agent 逻辑死循环”。
•
T (任务)： 某个意图模糊的 Case 导致 Supervisor 无法判定归属，不断在两个 Agent 之间反复路由，造成 Token 消耗激增和用户端卡死。
•
A (行动)： 我紧急叫停了该意图的 AI 路由，改由人工兜底。随后在产品逻辑上增加了“路由计数器”，规定同一个任务在 Agent 间流转超过 3 次必须报错，并优化了 Supervisor 的“意图未知（Unknown）”处理逻辑。
•
R (结果)： 此后再未出现过逻辑环路，这也成了我们后来的一项标准安全设计准则。
常见面试问题预览
Q: 为什么用Supervisor模式而不是让Agent直接互相调用？
A: Supervisor模式的优势在于集中控制，便于追踪和调试；避免Agent之间形成循环依赖；Supervisor可以做全局优化，比如并行调度多个Agent；出错时有统一的错误处理和回退机制。
Q: 三层记忆的设计原则是什么？
A: 参考了人类认知的记忆模型。工作记忆对应当前注意力焦点，速度最快但容量有限；短期记忆用Redis实现30分钟TTL，保持对话上下文连贯性；长期记忆用向量数据库存储知识库和用户历史，支持语义相似度检索。
Q: MCP协议相比直接调用函数有什么优势？
A: MCP是标准化协议，工具描述用JSON Schema，AI可以自动发现和理解工具能力，不需要硬编码工具调用逻辑；支持动态工具注册，新增工具不需要修改Agent代码；协议层做了权限控制和参数验证。
📖 参考项目
本项目设计参考了以下企业级开源项目，建议结合阅读：