三面综合：系统设计与综合素养（15题）

考察重点：系统设计能力、项目全局视角、技术判断力、协作与软实力答题要求：端到端分层架构思维，能从需求分析推到上线运维全链路系统设计题建议答题时间：15-20分钟（白板画图 + 分层讲解）行为面建议答题时间：3-5分钟/题

一、系统设计场景题

1. 设计企业内部知识库问答 Agent，支持文档上传、多轮问答、工具查业务数据库，画出分层架构。

分档：三面综合

高分答题思路：

分层架构图：

┌─────────────────────────────────────────────────────┐
│                    接入层                             │
│  Web UI │ API Gateway │ WebSocket(SSE) │ 权限认证    │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│                   Agent 编排层                        │
│  ┌─────────┐  ┌──────────┐  ┌──────────────────┐    │
│  │ 路由器   │→│ 意图识别  │→│ Agent 调度器      │    │
│  │         │  │          │  │ (状态机/Plan-Solve)│   │
│  └─────────┘  └──────────┘  └────────┬─────────┘    │
│                                       │              │
│              ┌────────────────────────┼────────┐    │
│              ▼                        ▼        ▼    │
│  ┌──────────────┐    ┌──────────────┐ ┌────────┐  │
│  │ 知识库 Agent  │    │ 数据库 Agent  │ │闲聊Agent│  │
│  │ (RAG 检索)   │    │ (Text2SQL)   │ │        │  │
│  └──────┬───────┘    └──────┬───────┘ └────────┘  │
└─────────┼───────────────────┼─────────────────────┘
          │                   │
┌─────────▼───────────────────▼─────────────────────┐
│                    工具层                            │
│  ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────────┐  │
│  │向量检索   │ │SQL执行 │ │文档解析│ │摘要生成   │  │
│  │(Milvus)  │ │(MySQL) │ │(PDF等) │ │(LLM)     │  │
│  └──────────┘ └────────┘ └────────┘ └──────────┘  │
└─────────────────────────────────────────────────────┘
          │
┌─────────▼─────────────────────────────────────────┐
│                    数据层                            │
│  ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────────┐  │
│  │向量数据库  │ │业务DB  │ │文档存储 │ │对话历史   │  │
│  │(Milvus)  │ │(MySQL)│ │(MinIO) │ │(Redis)   │  │
│  └──────────┘ └────────┘ └────────┘ └──────────┘  │
└─────────────────────────────────────────────────────┘

关键设计要点：

文档上传与索引流程：
- 上传 → 文档解析（PDF/Word/Markdown）→ 文本分块（Chunk，512 token/块，128 token 重叠）
- 分块 → Embedding（BGE/M3E）→ 存入 Milvus
- 元数据存储：文档名/目录/更新时间/权限标签
多轮问答流程：
- User Query → 意图识别（知识问答 vs 数据查询 vs 闲聊）
- 知识问答 → RAG 检索 → 上下文拼装 → LLM 生成
- 数据查询 → Text2SQL → 执行 SQL → 结果格式化 → LLM 生成
- 多轮记忆：Redis 存会话历史，最近 5 轮 + 关键信息留存
权限设计：
- 文档级权限：上传时标记部门/角色可见范围
- 查询时过滤：向量检索加权限 filter，只返回有权限的文档块
- SQL 查询：基于角色的数据行级权限
高可用设计：
- Agent 编排层无状态，水平扩展
- LLM 推理服务独立部署，支持多模型热切换
- 文档索引异步处理，上传后 30s 内可检索

面试官追问点准备：
"文档更新后如何同步向量索引？" → 增量索引：监听文档变更事件，异步重新 Embedding 更新对应 chunk
"如何处理多格式文档？" → 统一解析层：PDF 用 PyMuPDF，Word 用 python-docx，统一输出纯文本 + 结构标记
"Text2SQL 准确率怎么保证？" → Schema 感知（注入表结构注释）+ SQL 校验层（语法检查 + 安全校验）+ 执行前预览

2. 开发代码解释 Agent，支持执行 Python 代码、文件读写、沙箱隔离，怎么保障安全？

分档：三面综合

高分答题思路：

架构设计：

┌─────────────────────────────────────────┐
│            代码解释 Agent                │
│  ┌───────────┐  ┌─────────────────┐    │
│  │ 理解意图   │→│ 生成代码 + 解释   │    │
│  └───────────┘  └────────┬────────┘    │
│                          │             │
│                 ┌────────▼────────┐    │
│                 │  代码安全审查    │    │
│                 │  (AST 分析)     │    │
│                 └────────┬────────┘    │
└──────────────────────────┼─────────────┘
                           │
┌──────────────────────────▼─────────────┐
│            沙箱执行环境                  │
│  ┌─────────────────────────────────┐   │
│  │  Docker 容器 (只读根文件系统)     │   │
│  │  - 无网络访问                    │   │
│  │  - CPU/内存限制 (2C4G)          │   │
│  │  - 执行超时 30s                  │   │
│  │  - 临时文件系统 tmpfs            │   │
│  └─────────────────────────────────┘   │
└─────────────────────────────────────────┘

安全保障五层防线：

层级	措施	防御目标
L1 代码审查	AST 分析，禁止 import os/subprocess/socket 等	防止系统调用
L2 资源限制	Docker --memory=4g --cpus=2 --pids-limit=100	防止资源耗尽
L3 网络隔离	Docker --network=none	防止数据外泄/网络攻击
L4 文件隔离	只读根文件系统 + tmpfs 临时目录	防止文件篡改
L5 执行控制	超时 30s kill + 输出截断 10KB	防止死循环/输出爆炸

代码安全审查实现：

python

import ast

FORBIDDEN_MODULES = {"os", "subprocess", "socket", "shutil", 
                     "ctypes", "multiprocessing", "threading"}

def check_code_safety(code: str) -> tuple[bool, str]:
    try:
        tree = ast.parse(code)
    except SyntaxError as e:
        return False, f"语法错误: {e}"
    
    for node in ast.walk(tree):
        # 检查 import
        if isinstance(node, ast.Import):
            for alias in node.names:
                if alias.name.split('.')[0] in FORBIDDEN_MODULES:
                    return False, f"禁止导入模块: {alias.name}"
        # 检查函数调用中的 eval/exec
        if isinstance(node, ast.Call):
            if isinstance(node.func, ast.Name) and node.func.id in ("eval", "exec", "compile"):
                return False, f"禁止使用 {node.func.id}()"
        # 检查 open 调用的模式
        if isinstance(node, ast.Call) and isinstance(node.func, ast.Name) and node.func.id == "open":
            # 只允许只读模式
            ...
    
    return True, "安全检查通过"

文件读写安全：

工作目录限制在 /workspace/（tmpfs 挂载）
文件大小限制：单文件 < 10MB，总量 < 100MB
文件类型白名单：txt/csv/json/py/xlsx 等
敏感文件检测：上传文件不含密钥/密码模式

加分点： "除了静态 AST 审查，我们还加了运行时监控——用 strace 追踪容器的 syscall 调用，如果出现 fork/exec/connect 等异常 syscall 直接 kill 进程。这是第二道防线，防止 AST 绕过（比如通过 importlib 动态导入）。"

3. 多租户客服 Agent 平台，租户独立知识库、独立 prompt、权限隔离，架构如何拆分？

分档：三面综合

高分答题思路：

架构设计：

┌──────────────────────────────────────────────────┐
│                   接入层                          │
│  租户识别 → 权限校验 → 请求路由                    │
└──────────────────────┬───────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────┐
│              租户配置中心                          │
│  ┌────────────┐ ┌───────────┐ ┌──────────────┐  │
│  │ 知识库配置  │ │Prompt 模板│ │ 工具权限配置  │  │
│  │ (collection│ │ (tenant_id│ │ (tool_white- │  │
│  │  per tenant│ │  → prompt)│ │  list)       │  │
│  └────────────┘ └───────────┘ └──────────────┘  │
└──────────────────────┬───────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────┐
│              Agent 执行层（无状态）                │
│  按租户配置动态加载：                               │
│  - Prompt 模板                                    │
│  - 可用工具列表                                    │
│  - 知识库 collection                              │
│  - 模型配置（租户可选不同模型）                     │
└──────────────────────┬───────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────┐
│              共享基础设施                          │
│  ┌──────────┐ ┌────────┐ ┌────────┐ ┌────────┐  │
│  │Milvus    │ │MySQL   │ │Redis   │ │LLM集群 │  │
│  │(多集合)  │ │(租户隔离│ │(租户命名│ │(多模型 │  │
│  │          │ │ 表/Schema│ │ 空间)  │ │ 路由)  │  │
│  └──────────┘ └────────┘ └────────┘ └────────┘  │
└──────────────────────────────────────────────────┘

隔离方案选择：

隔离层级	方案	隔离度	成本	适用场景
知识库	Milvus 多 Collection	高	低	推荐
Prompt	配置表按 tenant_id 隔离	高	低	推荐
对话历史	Redis key 前缀 + TTL	高	低	推荐
业务数据	MySQL 多 Schema 或行级权限	高	中	看数据量
模型	大租户独立模型实例	最高	高	大客户
计算	K8s 命名空间隔离	最高	高	合规要求

关键设计决策：

共享 Agent 执行层：无状态设计，按租户配置动态加载，不为每个租户跑独立实例
共享 LLM 集群：多租户共享，按租户配额限流（令牌桶 + 优先级队列）
独立知识库：每个租户独立的 Milvus Collection，权限严格隔离
独立 Prompt：配置中心管理，支持版本控制和 A/B 测试

租户配额管理：

QPS 限流：免费 10 QPS，标准 50 QPS，企业 200 QPS
Token 配额：月度 token 限额，超额降级到更小模型
存储配额：知识库容量限制，按套餐分级

加分点： "最大的设计挑战不是隔离，而是'共享 vs 独立'的平衡。共享层做得太多，一个租户的 Badcase 影响所有租户；独立层做得太多，成本爆炸。我们的原则是：数据层必须隔离，计算层尽量共享，模型层看付费级别。"

4. 做一个离线批量数据处理 Agent，支持上万条任务并行调度、失败重试、进度监控。

分档：三面综合

高分答题思路：

架构设计：

┌──────────────────────────────────────────┐
│            任务提交层                      │
│  批量任务定义 (DAG) → 任务拆分 → 入队      │
└────────────────┬─────────────────────────┘
                 │
┌────────────────▼─────────────────────────┐
│            调度层 (Temporal/Celery)        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│  │ 任务队列  │ │ 优先级   │ │ 依赖编排  │  │
│  │ (Redis)  │ │ 调度器   │ │ (DAG)    │  │
│  └──────────┘ └──────────┘ └──────────┘  │
└────────────────┬─────────────────────────┘
                 │
┌────────────────▼─────────────────────────┐
│            Worker 集群 (K8s)              │
│  Worker×N (自动伸缩)                      │
│  每个 Worker:                              │
│  1. 拉取任务                               │
│  2. Agent 执行 (LLM 调用 + 工具调用)       │
│  3. 结果写入存储                           │
│  4. 上报状态                               │
└────────────────┬─────────────────────────┘
                 │
┌────────────────▼─────────────────────────┐
│            存储与监控层                    │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│  │ 结果存储  │ │ 失败队列  │ │ 监控面板  │  │
│  │ (S3/DB)  │ │ (死信队列)│ │ (Grafana)│  │
│  └──────────┘ └──────────┘ └──────────┘  │
└──────────────────────────────────────────┘

关键设计要点：

任务拆分策略
- 大任务拆成子任务（每批 100 条），子任务可并行
- DAG 描述任务间依赖关系
- 幂等设计：每个子任务有唯一 ID，重试不会产生重复结果
并行调度
- Worker 数量根据队列深度自动伸缩（K8s HPA）
- 每个 Worker 并发处理 5-10 个子任务（asyncio 协程）
- LLM 调用用连续批处理（Continuous Batching）提升吞吐
失败重试
- 自动重试 3 次，指数退避（1s → 2s → 4s）
- 重试失败 → 进入死信队列 → 人工介入
- 部分失败不阻塞整体：失败任务标记，成功任务正常推进
进度监控
- 实时进度：已完成/总数、成功率、平均耗时、预计剩余时间
- 异常告警：成功率 < 90%、单任务耗时 > 5min、队列堆积 > 1000
- 断点续跑：任务状态持久化，中断后从上次位置恢复
资源控制
- LLM API 限流感知：Worker 根据剩余配额动态调整并发数
- 内存控制：大文件流式处理，不一次性加载
- 超时保护：单任务最长 5min，超时 kill

加分点： "我们用 Temporal 做调度引擎——它的优势是 workflow 状态持久化 + 内置重试/超时/补偿。对于万级任务，关键是控制 LLM API 的并发——不是 Worker 越多越好，而是要匹配 API rate limit。我们做了令牌桶限流器，Worker 先拿令牌再调 LLM，避免 429。"

5. 设计 Agent 运维后台：可视化状态流、Badcase 检索、Prompt 在线调试、评测报表。

分档：三面综合

高分答题思路：

功能模块设计：

┌──────────────────────────────────────────────────┐
│                  Agent 运维后台                     │
├──────────┬──────────┬──────────┬─────────────────┤
│  状态流   │ Badcase  │ Prompt   │  评测报表        │
│  可视化   │ 检索     │ 调试     │                 │
├──────────┼──────────┼──────────┼─────────────────┤
│ • 实时    │ • 关键词  │ • 在线    │ • 每日/周报     │
│   状态机  │   搜索   │   编辑    │ • 趋势图        │
│   展示    │ • 条件   │   Prompt │ • 分维度统计    │
│ • 节点    │   筛选   │ • 实时    │ • Badcase      │
│   耗时    │ • 语义   │   预览    │   分布分析     │
│   热力图  │   搜索   │   输出    │ • 模型对比     │
│ • 执行    │ • Badcase│ • A/B    │ • 工具调用      │
│   轨迹    │   聚类   │   测试    │   统计         │
│   回放    │ • 根因   │ • 版本    │ • 灰度对比     │
│          │   标注   │   管理    │                │
└──────────┴──────────┴──────────┴─────────────────┘

各模块核心功能：

1. 可视化状态流

实时展示当前请求的状态机流转路径
每个节点显示：耗时、成功率、token 消耗
异常节点高亮（超时/失败/重试）
点击节点可展开详细输入输出
支持 trace 回放：选中历史请求，逐步回放执行轨迹

2. Badcase 检索

多维筛选：时间范围 × 意图 × 工具 × 错误类型 × 用户反馈
全文搜索：对用户 query 和 Agent 回复做全文检索
语义搜索：输入问题描述，Embedding 检索相似 Badcase
Badcase 聚类：自动按根因聚类，展示 Top N 问题类别
根因标注：支持人工标注根因类型，沉淀到知识库

3. Prompt 在线调试

左侧编辑器写 Prompt，右侧实时预览 LLM 输出
支持变量注入：从测试集选取样本数据填充 Prompt 变量
A/B 对比：左右两列对比新旧 Prompt 的输出差异
版本管理：每次保存自动生成版本号，支持回滚
批量测试：一键跑评测集，输出准确率/格式合规率等指标

4. 评测报表

核心指标趋势图：意图准确率、工具调用准确率、任务完成率（日/周/月）
分维度统计：按意图/工具/用户群体/模型版本交叉分析
灰度对比：新版本 vs 旧版本的指标对比，支持统计显著性检验
Badcase 分布：饼图/柱状图展示各根因类型占比
自动报告：每日自动生成评测报告推送到飞书/钉钉

技术选型：

前端：React + Ant Design + D3.js（状态流图）/ ECharts（报表）
后端：FastAPI + PostgreSQL（持久化）+ Elasticsearch（日志检索）+ ClickHouse（指标统计）
实时推送：WebSocket 推送状态更新

加分点： "运维后台的核心价值不只是'看到问题'，而是'缩短从问题发现到修复的闭环'。我们做了'一键创建调试任务'：在 Badcase 详情页直接点击 → 自动填充上下文到 Prompt 调试器 → 调试完成后一键发布灰度。整个'发现→定位→修复→验证'闭环从 2 天缩短到 2 小时。"

二、项目管理与行为面

6. 项目中最大技术难点是什么？完整讲清问题、你的方案、收益数据。

分档：三面综合

高分答题思路（STAR 框架）：

答题模板：S (Situation)：项目背景 + 面临的挑战 T (Task)：我的职责和目标 A (Action)：具体做了什么（技术方案 + 决策过程） R (Result)：量化收益 + 业务影响

示例答题框架：

S - 背景： "我们的 Agent 平台上线后，工具调用准确率只有 72%，导致 28% 的用户请求无法正确完成。核心问题是 LLM 在 15+ 工具中选择正确的工具时准确率不稳定。"

T - 任务： "我的目标是：在 2 个月内将工具调用准确率提升到 90%+，同时不增加单次推理延迟。"

A - 方案（展示技术深度和决策过程）：

根因分析：分析了 500 个 Badcase，发现 60% 的错误来自工具描述不清晰，30% 来自上下文过长导致工具列表被截断
方案设计：
- L1：重写工具描述（结构化 + 举例），准确率 +8%
- L2：工具分层路由（先分类再选工具），减少每次选择的工具数，准确率 +6%
- L3：工具选择置信度阈值 + 反问用户兜底，准确率 +5%
取舍：L2 增加了一次轻量分类调用（+30ms），但整体准确率提升显著，延迟在可接受范围

R - 收益：

工具调用准确率：72% → 91%（+19pp）
用户任务完成率：75% → 88%（+13pp）
单次推理延迟：仅增加 30ms（< 5% 影响）
工具相关投诉量下降 65%

加分点： 主动提到"这个方案不是完美的——L2 的分层路由增加了系统复杂度，后续如果工具数量继续增长到 30+，可能需要引入工具向量检索。我们提前预留了这个扩展点。"

7. 跨团队需求排期冲突，业务方强压工期，你如何协调平衡？

分档：三面综合

高分答题思路：

核心原则：用数据说话，给选择题而非判断题

处理流程：

明确约束
- 业务方要什么？什么时候要？为什么急？
- 技术方需要多少时间？瓶颈在哪里？
拆分优先级
- P0 核心路径：必须做，不能砍
- P1 重要功能：可以做但可以简化
- P2 优化项：可以延后
给出选项（而非说"不行"）
- 方案A：按原计划全量交付，时间 X（推荐）
- 方案B：P0+P1 精简版先上，P2 延后，时间 Y（折中）
- 方案C：P0 最小可用版本先上，时间 Z（最快但功能少）
- 每个方案列出：交付内容、时间、风险、质量影响
数据支撑
- 如果赶工导致测试不足，线上 Badcase 率预计 +X%
- 如果先上精简版，用户覆盖率 Y%，满足核心需求
达成共识后落地
- 书面确认方案和排期
- 每周同步进度，提前预警
- 上线后复盘，沉淀经验

关键原则： "不要说'来不及做不了'，要说'如果要在 X 时间上线，可以做 A/B/C 三个方案，建议选 B，因为...'。给业务方决策权，但用专业判断引导。"

8. 项目技术方案存在两种路线，团队分歧大，你怎么推动统一选型？

分档：三面综合

高分答题思路：

处理流程：

理清分歧本质
- 是技术层面的分歧（性能 vs 灵活性）？
- 还是经验偏好（熟悉 A vs 熟悉 B）？
- 还是风险承受能力差异（求稳 vs 求新）？
建立评估框架（对齐标准）
- 列出评估维度：开发成本、性能、可维护性、扩展性、团队学习成本、风险
- 每个维度打分（1-5 分），两方案对比
- 权重按业务阶段调整（初期重速度，稳定期重可维护性）
数据验证（用事实说话）
- 关键维度做 POC 验证（如性能：跑 benchmark）
- 对比已有案例（其他公司/团队用 A 和 B 的经验）
- 如果可能，AB 测试线上效果
决策机制
- 评估表对齐后，组织技术评审会
- 邀请架构师/技术负责人参与，不只是开发团队
- 如果仍然分歧，按"谁负责谁决策"原则，但需说明理由
- 记录决策文档，明确 trade-off 和后续可调整方案
落地后保障
- 设定 checkpoint：上线 1 个月后评估是否需要调整
- 如果选了 A，保留 B 方案的关键设计文档，降低后续切换成本

加分点： "我的经验是：80% 的技术选型分歧不是技术问题，而是信息不对称——A 方案的支持者不了解 B 的优势，反之亦然。所以第一步是让双方互相'上课'，把对方方案的优点和自己的痛点摆出来。对齐信息后，分歧通常就缩小了。"

9. 项目上线后出现线上 P0 故障，完整复盘流程和整改措施。

分档：三面综合

高分答题思路：

故障处理流程（5 步法）：

应急响应（发现 → 止血）
- 发现方式：监控告警 / 用户反馈
- 第一动作：评估影响范围，决定是否回滚
- 止血优先于定位：先恢复服务，再查根因
- 通报机制：拉群同步现状，每 15 分钟更新一次
根因定位（止血 → 定位）
- 查看变更记录：最近发布了什么？
- 分层排查：接入层 → Agent 层 → 工具层 → 模型层 → 数据层
- 利用 trace_id 快速定位故障环节
- 如果是 LLM 输出异常 → 查 Prompt 变更 / 模型版本更新
修复验证
- 修复方案 code review
- 在测试环境验证
- 灰度发布（先 5% → 20% → 100%）
- 确认指标恢复正常
复盘总结（事后 48 小时内）
- 时间线：发现时间 → 响应时间 → 止血时间 → 完全恢复时间
- 根因分析：5 Why 追问，找到根本原因而非表面原因
- 影响评估：影响用户数、影响时长、业务损失
- 整改措施：短期（补监控/加告警）+ 中期（加防护/改流程）+ 长期（架构优化）
整改落地跟踪
- 每项整改措施指定负责人和 deadline
- 周会跟踪进度直到全部完成
- 整改完成后回归验证

复盘文档模板：

## 故障复盘：[故障标题]
### 时间线
- 14:00 告警触发
- 14:05 确认 P0 故障，拉群
- 14:10 决定回滚
- 14:15 回滚完成，服务恢复
- 14:30 根因定位
### 根因
[5 Why 分析]
### 影响
- 影响用户数：X
- 影响时长：15 分钟
- 业务影响：Y
### 整改措施
| 措施 | 类型 | 负责人 | Deadline | 状态 |
|------|------|--------|----------|------|
| 增加工具输出 Schema 校验 | 短期 | XXX | 2024-XX | 完成 |
| Prompt 变更增加自动化测试 | 中期 | XXX | 2024-XX | 进行中 |
| Agent 层增加熔断机制 | 长期 | XXX | 2024-XX | 待启动 |

关键原则： "复盘不是追责，是改进。文化上要鼓励'暴露问题'而非'隐藏问题'。每次故障都是改进系统的机会——如果同样的故障发生两次，说明第一次复盘没做到位。"

10. 你对 Agent 领域未来技术路线怎么看？长期技术成长规划。

分档：三面综合

高分答题思路：

Agent 技术趋势判断（3 个方向）：

Agent 自主性提升
- 从"工具调用器"到"自主决策者"：Agent 能自己规划、执行、反思、调整
- 关键突破点：长程推理能力（Long-horizon Planning）、自我评估能力
- 时间线：2-3 年内，在特定领域（代码/数据分析）实现较高自主性
多 Agent 协作成熟化
- 从简单的 Master-Worker 到复杂的 Agent 社会：角色分工、协商、竞争
- 关键突破点：Agent 间通信协议标准化、协作效率优化
- 挑战：多 Agent 系统的可控性和可预测性
Agent 工程化标准化
- 从"每个团队自研"到"标准化的 Agent 开发框架/平台"
- 类比 Web 开发演进：从 CGI 到 Flask 到 K8s
- 关键方向：Agent 可观测性标准、评测标准、安全标准

个人成长规划（展示目标感）：

短期（1-2年）：深耕 Agent 工程化——评测体系、可观测性、多 Agent 编排，成为团队 Agent 方向核心骨干
中期（3-5年）：拓展技术广度——从 Agent 延伸到 LLM 训练/推理优化/多模态，能独立负责 AI Agent 产品线
长期：技术影响力——参与 Agent 行业标准制定，或在大厂推动一个有影响力的 Agent 平台落地

关键原则： "回答这个问题要展示两点：一是对领域有真实理解（不是泛泛而谈'AI是未来'），二是个人规划与应聘岗位有契合度。避免说'我想创业'——大厂面试官想听的是你能在团队内成长。"

11. 过往项目中，你主动推动了哪些技术优化落地，带来量化收益？

分档：三面综合

高分答题思路（举 2-3 个具体例子）：

示例框架：

优化一：工具调用准确率提升

发现：通过 Badcase 分析发现工具描述不清晰导致误调用
推动：主动重写 15 个工具的描述（结构化 + 示例），增加分层路由
收益：准确率 72% → 91%，工具相关投诉下降 65%
关键：不是等分配任务，是主动发现问题并推动解决

优化二：推理成本优化

发现：所有请求都用大模型，简单请求浪费资源
推动：设计分级路由——简单请求走小模型，复杂请求走大模型
收益：月度 API 成本降低 40%，平均延迟降低 35%
关键：从业务数据中发现优化空间，而不是纯技术角度

优化三：评测体系从 0 到 1

发现：团队没有系统化评测，每次上线靠人工抽检
推动：搭建自动化评测平台（数据集 + 自动指标 + 报表）
收益：评测覆盖率从 20% 提升到 95%，上线周期从 2 周缩短到 3 天
关键：识别到基础设施缺失并主动补齐

关键原则： "主动推动 = 不是被分配的 + 有量化收益 + 可复现的方法论。每个例子都要说清'怎么发现的'、'怎么推动的'（遇到什么阻力如何克服）、'收益是什么'。"

12. 为什么选择腾讯做 Agent 方向，对比其他大厂 AI 团队你的考量？

分档：三面综合

高分答题思路：

回答框架：行业认知 + 公司优势 + 个人匹配

行业认知
- Agent 是 LLM 从"对话工具"到"生产力工具"的关键桥梁
- 2024-2025 年是 Agent 工程化的关键窗口期
- 大厂优势：场景丰富、数据量大、工程能力强、用户基数大
腾讯的优势（结合具体业务线）
- 场景优势：微信/企业微信/腾讯云/腾讯文档等丰富的 Agent 落地场景
- 混元大模型：自研大模型 + 开源生态，Agent 有底层模型支持
- 技术积累：在 NLP/对话/推荐领域有深厚积累
- 用户规模：月活十亿级产品，Agent 优化的边际收益巨大
个人匹配
- 我的 Agent 工程经验（评测体系/工具调用优化/多 Agent 编排）与腾讯 Agent 平台建设需求匹配
- 我关注 Agent 工程化/可观测性/评测，这是腾讯大规模 Agent 落地需要解决的痛点
- 希望在大规模场景验证自己的技术方案
对比其他大厂（展示你做过调研，但不要贬低）
- 阿里：电商/云场景强，Agent 偏向商业化
- 字节：推荐/内容场景强，Agent 偏向 C 端交互
- 百度：文心大模型 + 搜索场景
- 腾讯：社交 + 办公 + 云，Agent 落地场景最多元

关键原则： "不要泛泛地说'腾讯技术好'，要具体到业务线和场景。最好能提到腾讯最近在 Agent 方面的具体动作（如混元 Agent 平台、腾讯智能体开发平台等），展示你真的做过功课。"

13. 你理想的 AI Agent 团队是什么样，不能接受什么工作模式？

分档：三面综合

高分答题思路：

理想团队的 4 个维度：

技术文化
- 数据驱动决策，而非拍脑袋
- 鼓励技术探索和创新，有容错空间
- 重视工程质量（评测/监控/文档），不只是"能跑就行"
团队协作
- 清晰的职责边界 + 开放的沟通氛围
- 技术 PM 懂技术，能做合理排期
- 跨团队协作有流程保障，不是纯靠"刷脸"
成长环境
- 有技术大佬可以学习
- 技术分享常态化
- 支持参加学术会议/发表论文
业务场景
- 有真实的、大规模的落地场景
- 技术和业务有正向循环：技术驱动业务 → 业务反哺数据 → 数据提升技术

不能接受的工作模式（说实话但不要极端）：

❌ 纯执行机器：只接需求不思考，没有技术决策参与权
❌ 无度量驱动：效果好不好全凭感觉，没有评测体系
❌ 技术债务不还：永远在赶新需求，不回头优化
❌ 信息孤岛：团队间不共享知识，重复造轮子

关键原则： "不能接受的事项要合理，不要显得偏激。核心表达'我想要一个专业、高效、有成长空间的环境'，而不是在列一堆抱怨。"

三、腾讯二面深度追问

14. 线上 Agent 接口 QPS、平均 RT、99 分位延迟，怎么压测优化到目标指标？

分档：三面综合

高分答题思路：

性能指标定义：

QPS：每秒处理的 Agent 请求数
平均 RT：从请求到响应的平均耗时
P99 延迟：99% 的请求在多少 ms 内完成

压测方案：

基准压测
- 工具：Locust / wrk / 自研压测平台
- 场景：按线上流量分布构造压测数据（不同意图比例）
- 递增加压：10 → 50 → 100 → 200 QPS，观察拐点
瓶颈定位
- 分层耗时分析：路由 → 意图识别 → 工具调用 → LLM 生成
- 通常瓶颈在 LLM 调用（占总 RT 的 60-80%）
- 工具调用如果是外部 API，也可能成为瓶颈
优化手段（按效果排序）

手段	效果	实施难度
流式输出	首字延迟降低 50%+	低
Prompt 精简	RT 降低 20-30%	低
模型分级路由	简单请求 RT 降低 60%	中
结果缓存	缓存命中 RT 降低 90%	中
并行工具调用	多工具场景 RT 降低 40%	中
KV Cache 复用	推理 RT 降低 20%	高（需 vLLM）
模型量化	RT 降低 30-50%	高

P99 优化重点
- P99 高通常是因为尾部延迟（长尾请求）
- 长尾原因：上下文过长、工具超时、模型偶发慢响应
- 解决：超时熔断 + 降级返回 + 请求超时控制

目标指标参考：

简单对话：QPS 200+，平均 RT < 500ms，P99 < 1.5s
工具调用：QPS 50+，平均 RT < 2s，P99 < 5s
复杂推理：QPS 20+，平均 RT < 5s，P99 < 10s

数据佐证模板： "我们优化前 P99 是 12s，通过 Prompt 精简（-2s）+ 模型分级路由（-4s）+ 流式输出（首字-3s）+ 超时降级（P99-2s），最终 P99 降到 4s 以内。最大收益来自模型分级路由——70% 的简单请求走了小模型。"

15. 接入第三方 LLM API 存在限流、不稳定，你的降级、缓存方案是什么？

分档：三面综合

高分答题思路：

多层级容灾方案：

请求 → [限流检查] → [缓存检查] → 主模型 → 备选模型 → 降级模型 → 规则回复
         │              │           │          │           │
         ▼              ▼           ▼          ▼           ▼
      令牌桶         结果缓存     OpenAI    Azure     自部署
      限流           语义缓存     GPT-4     GPT-4     7B模型

1. 限流管理

令牌桶限流：按 API 的 RPM/TPM 限制配置令牌桶
多 Key 轮询：多个 API Key 轮流使用，提升总 QPS 上限
请求排队：超限请求进入队列，不直接拒绝（等待 < 3s）

2. 缓存策略

精确缓存：完全相同的 Prompt → 缓存结果（TTL 5min）
语义缓存：Embedding 相似度 > 0.95 → 复用结果（需校验）
前缀缓存：相同 System Prompt → KV Cache 复用（vLLM Prefix Caching）
缓存命中率：典型 10-20%，高峰期可缓解 15% 的流量

3. 降级链

L1 主模型：OpenAI GPT-4（效果最好）
L2 备选模型：Azure GPT-4（不同通道，避免同时故障）
L3 降级模型：自部署 7B/13B 模型（延迟低但效果差）
L4 规则回复：预设回复模板 + 推荐引导

4. 自动切换逻辑

python

async def call_llm_with_fallback(prompt: str):
    models = [
        ("openai-gpt4", timeout=10, max_retries=2),
        ("azure-gpt4", timeout=10, max_retries=2),
        ("local-7b", timeout=5, max_retries=1),
    ]
    for model, timeout, retries in models:
        try:
            return await call_with_retry(model, prompt, timeout, retries)
        except (RateLimitError, TimeoutError, ServiceUnavailableError):
            continue
    
    # 所有模型都失败 → 降级
    return {
        "reply": "抱歉，系统繁忙，请稍后重试。",
        "suggestion": get_faq_suggestion(prompt)  # 规则推荐
    }

5. 熔断恢复

熔断时间窗口：30s（避免频繁切换）
半开探测：30s 后放 10% 流量探测恢复
全量恢复：探测成功率 > 95% → 全量切回

加分点： "缓存策略中最有价值的是'前缀缓存'——因为所有请求共享同一个 System Prompt（~1K token），前缀缓存可以节省 30% 的推理计算。语义缓存要谨慎，我们早期有 case 是语义相似但意图不同导致返回错误结果，后来加了'语义缓存 + LLM 二次校验'才安全。"

16. 多 Agent 之间上下文传递存在信息丢失，你做了哪些兜底方案？

分档：三面综合（深度追问）

高分答题思路：

信息丢失的 4 种类型：

类型	原因	兜底方案
摘要丢失	上下文过长做摘要时遗漏关键信息	关键信息结构化提取，不进入摘要而是单独存储
序列化丢失	对象 → JSON → 反序列化时丢失类型信息	用 Pydantic Schema 严格约束序列化/反序列化
路由丢失	信息传递给错误的 Agent	路由时附带 metadata（意图标签 + 实体列表），接收方校验
累积丢失	多次传递后信息逐渐衰减	每 N 步做一次"信息完整性校验"，补全丢失的关键字段

兜底机制设计：

结构化上下文传递

python

class AgentContext(BaseModel):
    """所有 Agent 间传递的上下文必须符合此 Schema"""
    task_id: str                    # 任务 ID
    user_query: str                 # 原始用户问题（不丢失）
    key_entities: list[Entity]      # 关键实体
    decisions: list[Decision]       # 已确认的决策
    tool_results: list[ToolResult]  # 工具调用结果摘要
    constraints: list[str]          # 约束条件
    confidence: float               # 当前上下文完整度评估

关键信息保护
- 原始用户 Query 永远不被摘要/截断，完整传递
- 关键决策（如用户明确选择）标记为 protected: true，不可被覆盖
- 上下文中标记 must_have 字段，接收方校验是否齐全
完整性校验
- 每个 SubAgent 接收上下文后，先做完整性校验
- 校验失败 → 向 Master 报告缺失字段 → Master 补充或决定降级处理
- 示例：if not context.key_entities: request_more_context()
上下文版本管理
- 每次传递生成新的 context version
- 保留历史版本，支持回溯到任意节点
- 如果最终结果异常，可以回溯检查哪一步丢失了信息

数据佐证模板： "我们早期多 Agent 传递用自然语言摘要，信息丢失率约 15%。改为结构化 Schema + 完整性校验后，丢失率降到 2% 以下。关键是'原始 Query 不碰'+'关键字段 protected'——这两条规则解决了 80% 的问题。"

17. 如果让你重构当前 Agent 项目架构，你会改掉哪些设计缺陷？

分档：三面综合（深度追问）

高分答题思路：

答题策略： 展示反思能力但不否定原有设计——每个"缺陷"都要说明"当时的约束"和"现在为什么需要改"。

典型重构方向（选 3-4 个展开）：

工具调用从"同步"改为"异步+流式"
- 原设计：所有工具同步调用，Agent 等待结果
- 问题：慢工具拖累整体延迟
- 重构：工具调用异步化 + 流式返回中间状态
- 收益：用户感知延迟降低 40%
上下文管理从"固定窗口"改为"动态管理"
- 原设计：固定保留最近 5 轮
- 问题：重要信息在第 6 轮被丢弃
- 重构：基于信息重要性的动态保留 + 关键信息池
- 收益：多轮任务完成率 +8%
评测从"人工抽检"改为"自动+人工"
- 原设计：上线前人工抽检 50 条
- 问题：覆盖率低，Badcase 发现滞后
- 重构：自动化评测 1000+ 条 + LLM-as-Judge + 人工抽检异常 case
- 收益：Badcase 发现时间从 3 天 → 1 小时
Agent 编排从"硬编码流程"改为"配置化编排"
- 原设计：流程写死在代码里
- 问题：每次调整流程需要改代码发版
- 重构：流程配置化（YAML/JSON 描述 DAG），运行时加载
- 收益：流程调整从 2 天 → 30 分钟
监控从"结果埋点"改为"全链路追踪"
- 原设计：只记录最终输出
- 问题：Badcase 无法定位是哪个环节的问题
- 重构：trace_id 贯穿全链路，每环节记录输入/输出/耗时
- 收益：Badcase 定位时间从 30min → 3min

关键原则： "重构方案要分优先级——不是所有缺陷都需要立刻改。我的原则是：影响线上稳定性的最先改，影响开发效率的其次改，'锦上添花'的排后面。同时要考虑重构风险——每个改动都要有回滚方案。"

答题策略总结

要点	说明
系统设计	先画架构图，再逐层讲，每层说清"为什么这样设计"
白板能力	练习手画架构图，面试时 5 分钟内画出核心分层
STAR 框架	行为面用 Situation-Task-Action-Result 结构化回答
量化意识	每个优化都要有数据支撑（提升 X%、降低 Y ms）
反思能力	主动谈设计缺陷和重构方向，展示持续学习的心态
业务理解	技术方案要回到业务价值——"这个优化对用户/业务意味着什么"
提问环节	准备 2-3 个有深度的问题反问面试官，展示你的思考

三面综合：系统设计与综合素养（15题） ​

一、系统设计场景题 ​

1. 设计企业内部知识库问答 Agent，支持文档上传、多轮问答、工具查业务数据库，画出分层架构。 ​

2. 开发代码解释 Agent，支持执行 Python 代码、文件读写、沙箱隔离，怎么保障安全？ ​

3. 多租户客服 Agent 平台，租户独立知识库、独立 prompt、权限隔离，架构如何拆分？ ​

4. 做一个离线批量数据处理 Agent，支持上万条任务并行调度、失败重试、进度监控。 ​

5. 设计 Agent 运维后台：可视化状态流、Badcase 检索、Prompt 在线调试、评测报表。 ​

二、项目管理与行为面 ​

6. 项目中最大技术难点是什么？完整讲清问题、你的方案、收益数据。 ​

7. 跨团队需求排期冲突，业务方强压工期，你如何协调平衡？ ​

8. 项目技术方案存在两种路线，团队分歧大，你怎么推动统一选型？ ​

9. 项目上线后出现线上 P0 故障，完整复盘流程和整改措施。 ​

10. 你对 Agent 领域未来技术路线怎么看？长期技术成长规划。 ​

11. 过往项目中，你主动推动了哪些技术优化落地，带来量化收益？ ​

12. 为什么选择腾讯做 Agent 方向，对比其他大厂 AI 团队你的考量？ ​

13. 你理想的 AI Agent 团队是什么样，不能接受什么工作模式？ ​

三、腾讯二面深度追问 ​

14. 线上 Agent 接口 QPS、平均 RT、99 分位延迟，怎么压测优化到目标指标？ ​

15. 接入第三方 LLM API 存在限流、不稳定，你的降级、缓存方案是什么？ ​

16. 多 Agent 之间上下文传递存在信息丢失，你做了哪些兜底方案？ ​

17. 如果让你重构当前 Agent 项目架构，你会改掉哪些设计缺陷？ ​

答题策略总结 ​

三面综合：系统设计与综合素养（15题）

一、系统设计场景题

1. 设计企业内部知识库问答 Agent，支持文档上传、多轮问答、工具查业务数据库，画出分层架构。

2. 开发代码解释 Agent，支持执行 Python 代码、文件读写、沙箱隔离，怎么保障安全？

3. 多租户客服 Agent 平台，租户独立知识库、独立 prompt、权限隔离，架构如何拆分？

4. 做一个离线批量数据处理 Agent，支持上万条任务并行调度、失败重试、进度监控。

5. 设计 Agent 运维后台：可视化状态流、Badcase 检索、Prompt 在线调试、评测报表。

二、项目管理与行为面

6. 项目中最大技术难点是什么？完整讲清问题、你的方案、收益数据。

7. 跨团队需求排期冲突，业务方强压工期，你如何协调平衡？

8. 项目技术方案存在两种路线，团队分歧大，你怎么推动统一选型？

9. 项目上线后出现线上 P0 故障，完整复盘流程和整改措施。

10. 你对 Agent 领域未来技术路线怎么看？长期技术成长规划。

11. 过往项目中，你主动推动了哪些技术优化落地，带来量化收益？

12. 为什么选择腾讯做 Agent 方向，对比其他大厂 AI 团队你的考量？

13. 你理想的 AI Agent 团队是什么样，不能接受什么工作模式？

三、腾讯二面深度追问

14. 线上 Agent 接口 QPS、平均 RT、99 分位延迟，怎么压测优化到目标指标？

15. 接入第三方 LLM API 存在限流、不稳定，你的降级、缓存方案是什么？

16. 多 Agent 之间上下文传递存在信息丢失，你做了哪些兜底方案？

17. 如果让你重构当前 Agent 项目架构，你会改掉哪些设计缺陷？

答题策略总结