AI Agent 项目讲述技巧

面试讲项目不是背简历，而是证明你能定义问题、设计系统、处理失败并持续优化。

---

📌 Section Goals（本节目标）

• 掌握 AI Agent 项目的 30 秒、2 分钟、5 分钟、15 分钟四档讲法。
• 用 STAR + Tech 框架组织项目故事，避免流水账式回答。
• 针对算法岗与开发岗准备不同讲述重点。
• 学会回答“为什么这么设计”“指标是否可信”“失败怎么处理”等高频追问。
• 使用可运行脚本检查项目讲述是否缺少背景、动作、结果或复盘。

---

💡 Core Concepts（核心概念）

1. 面试官真正想听什么

项目讲述的目标不是展示你知道多少名词，而是让面试官判断：

• 你是否理解业务或研究问题。
• 你是否真的设计和实现过关键模块。
• 你是否能解释技术取舍，而不是只会调包。
• 你是否有指标意识和复盘能力。
• 你是否能把一次项目经验迁移到真实工作中。

2. STAR + Tech 框架

传统 STAR 适合行为面试，但 AI Agent 项目还需要补充技术细节。

模块	含义	Agent 项目中的表达
S: Situation	背景	为什么需要这个 Agent，原方案有什么痛点
T: Task	目标	要解决什么问题，用什么指标衡量成功
A: Action	行动	架构、模块、算法、工程实现
R: Result	结果	准确率、召回率、延迟、成本、用户反馈
Tech	技术取舍	为什么用 LangGraph，为什么这样设计 Memory / Tool / RAG

3. 好项目故事的 6 个关键词

场景清楚、目标明确、架构可画、难点具体、指标可信、复盘真实

只要缺一个，面试官就会觉得项目不够扎实。

4. 项目闭环六步法

准备项目故事时，不要只背 STAR 四段，而要提前回答六个闭环问题：

为什么要做？ -> 不做会怎样？ -> 为什么选这个方法？
-> 为什么不是其他方法？ -> 怎么验证真的有效？ -> 为什么收益能落到业务或研究价值上？

这六个问题能把项目从“我用了某个框架”拉回“我定义并解决了一个真实问题”。面试时至少覆盖其中四个，项目可信度会明显提高。

闭环问题	面试官想判断什么	Agent 项目回答示例
为什么要做	问题定义能力	“客服重复回答制度问题，人工处理成本高”
不做会怎样	业务或研究价值	“流程类问题仍依赖人工，响应慢且不可规模化”
为什么选这个方法	技术判断力	“复杂问题需要状态管理和工具调用，所以用 LangGraph 而不是单轮 prompt”
为什么不是其他方法	取舍能力	“Dify 适合快速验证，但底层评估和状态机控制不够可定制”
怎么验证有效	指标意识	“用 300 条 QA 集同时看 Recall@5、引用准确率和人工抽检”
收益如何落地	结果闭环	“P95 延迟下降、工具调用成功率提升、失败样本可持续回归”

---

🔍 Deep Understanding（深入理解）

四档项目讲法

30 秒版本：用于“简单介绍一个项目”

我做的是一个企业知识库 RAG Agent，目标是让员工能用自然语言查询制度和流程。
系统基于 FastAPI、Milvus 和 LangGraph，包含文档解析、混合检索、rerank、
引用溯源和评估集回归。我主要负责检索与评估模块，通过混合检索和重排把
Recall@5 从 68% 提升到 84%，并接入失败案例分析来持续优化。

结构：

项目是什么 + 为什么做 + 技术栈 + 我的贡献 + 结果

2 分钟版本：用于项目主线讲述

背景上，这个项目来自企业内部知识库场景，痛点是制度文档多、人工客服重复回答、
普通关键词搜索很难处理流程类问题。

目标上，我定义了两个核心指标：检索 Recall@5 和答案引用准确率。因为如果检索
不到正确文档，后面的生成再好也没有意义。

实现上，系统分成四层：文档解析层负责切分和清洗，检索层做 BM25 + dense
retrieval 的混合召回，生成层使用 LangGraph 管理检索、回答和反思流程，
评估层用 300 条自建 QA 做离线回归。

我的主要贡献是检索和评估模块。最初只有向量检索，流程类问题召回很差。
我加入关键词召回和 reranker，并按章节粒度重新切分文档，最终 Recall@5
从 68% 提升到 84%，引用准确率从 71% 提升到 87%。

复盘上，这个项目让我意识到 RAG 的核心不是“接一个向量库”，而是数据切分、
召回策略、评估集和失败案例闭环。

5 分钟版本：用于技术面深入展开

建议按这条线讲：

1. 业务背景：谁用、为什么需要、原方案问题。
2. 技术目标：核心指标和约束。
3. 系统架构：模块划分和数据流。
4. 关键难点：选 1-2 个讲深。
5. 方案取舍：为什么不用另一个方案。
6. 结果指标：提升幅度、数据来源、可信度。
7. 失败复盘：遇到的问题和下一步优化。

15 分钟版本：用于大厂深挖

15 分钟不是讲更多背景，而是讲清楚系统边界。

深挖方向	你要准备的内容
架构设计	状态机、模块边界、数据流、异常流
RAG	切分策略、embedding、召回、rerank、引用溯源
Agent	Planner、Tool Executor、Memory、Reflection、终止条件
评估	测试集来源、指标定义、人工抽检、失败样本
工程	并发、缓存、日志、监控、成本、部署
安全	Prompt 注入、权限控制、敏感信息、工具白名单

算法岗讲述重点

算法岗要突出“实验设计和可验证提升”。

推荐结构：

问题定义 -> baseline -> 方法改进 -> 数据集 -> 指标 -> 消融实验 -> 失败分析

示例：

我关注的是多跳问答场景下 RAG 召回不足的问题。baseline 是 BM25、dense
retrieval 和 GraphRAG。我发现 dense retrieval 对实体精确匹配不稳定，
GraphRAG 在小规模数据上构图成本较高，所以设计了 query decomposition
+ hybrid retrieval + reranker 的组合策略。实验集是 300 条人工标注问题，
最终 Recall@5 从 68% 提升到 84%。消融实验显示 reranker 贡献约 7 个点，
query decomposition 对多跳问题贡献更明显。

开发岗讲述重点

开发岗要突出“系统可用性和工程闭环”。

推荐结构：

业务场景 -> 系统架构 -> 核心模块 -> 异常处理 -> 性能优化 -> 部署监控 -> 业务结果

示例：

我把系统拆成文档处理、检索服务、Agent 编排、评估回归和日志监控五个模块。
线上最常见的问题不是模型答错，而是工具参数错误、检索为空和上下文过长。
所以我加入了工具 schema 校验、fallback 检索、上下文裁剪和日志 trace。
这些机制让工具调用成功率提升到 94%，P95 延迟从 4.8s 降到 1.6s。

面试追问地图

面试官追问	想考什么	回答重点
你为什么用 LangGraph？	框架理解	状态机、循环控制、人审节点、可观测性
为什么不用纯 prompt？	Agent 边界	任务需要工具调用、状态管理、多步规划
指标怎么定义？	评估意识	测试集、指标、人工抽检、失败样本
幻觉怎么处理？	可靠性	引用溯源、拒答策略、答案校验
工具调用失败怎么办？	工程能力	schema 校验、重试、fallback、日志
如果用户量扩大 10 倍？	系统设计	缓存、异步队列、限流、模型路由
如果数据有权限？	安全意识	ACL、租户隔离、工具白名单、审计日志

失败案例要主动准备

优秀的项目讲述一定包含失败案例。不要只讲“我做得很好”，要讲“我怎么发现问题并修掉”。

可准备三类失败：

1. 技术失败：检索不准、工具调用错、上下文过长、模型幻觉。
2. 工程失败：延迟太高、成本超预算、日志不可排查。
3. 产品失败：用户问题和测试集不一致，Demo 好看但真实使用差。

失败案例模板：

最开始我以为问题出在 prompt，但看 trace 后发现 70% 的错误来自检索阶段。
具体表现是用户问流程类问题时，向量检索只召回了定义文档，没有召回操作步骤。
我后来把文档切分从固定 token 改成章节级切分，并加入 BM25 补充实体匹配，
这个改动让流程类问题 Recall@5 提升了 13 个点。

---

💻 Code Examples（代码示例）

环境说明

• Python 版本：Python 3.10+
• 依赖：仅使用标准库
• requirements.txt：见 docs/04-interview/examples/requirements.txt

运行方式

cd AgentGuide
python docs/04-interview/examples/resume_storytelling_check.py --mode story

你可以用它检查什么

脚本会检查项目讲述是否包含：

• 背景：为什么做这个项目。
• 任务：目标和评价指标是什么。
• 行动：你做了什么技术动作。
• 结果：指标、产物或业务价值。
• 复盘：失败案例、取舍或下一步。

如果输出里提示缺少 result，说明你的故事很可能停留在“我做了一个系统”，但没有证明它有效。

---

🎯 Interview Questions（面试中如何考）

Q1：请你用 2 分钟介绍一个最有代表性的 Agent 项目

回答结构：

背景 -> 目标 -> 架构 -> 我的贡献 -> 指标 -> 复盘

不要上来就说“我用了 LangChain、Milvus、FastAPI”。先说问题，再说技术。

Q2：这个项目最大的技术难点是什么？

推荐答法：

最大的难点不是把链路跑通，而是让结果可评估、可迭代。
最初 Demo 能回答，但不知道哪里好哪里坏。所以我先构建测试集，
再拆分 Recall@5、引用准确率、答案相关性三个指标，最后根据失败样本
反推切分、召回和 rerank 策略。

Q3：如果重新做一遍，你会怎么改？

回答要体现成长：

• 数据侧：扩大评估集，加入真实用户问题。
• 架构侧：把 Agent 状态、工具日志、评估结果统一 trace。
• 模型侧：根据任务类型做模型路由，控制成本。
• 安全侧：加入权限过滤、prompt 注入检测和敏感信息脱敏。

Q4：你如何证明这个 Agent 比普通 RAG 更好？

回答思路：

1. 说明普通 RAG 的 baseline。
2. 说明 Agent 增加了什么能力。
3. 用分任务指标证明增益。

我不会直接说 Agent 更高级，而是按任务类型对比。对于简单定义类问题，
普通 RAG 和 Agent 差距不大；但对于需要多步查询、工具计算、条件判断的问题，
Agent 的任务完成率更高。我的测试集中多跳任务完成率从 61% 提升到 78%，
代价是平均响应时间增加约 0.8s，所以我只在复杂问题路由到 Agent。

Q5：如果面试官质疑项目太像教程怎么办？

回答重点：

• 承认基础框架来自公开资料。
• 强调你做了自己的场景适配、数据集、指标和失败分析。
• 展示你不只是跑通 Demo，而是做了可复现改进。

基础链路确实参考了公开教程，但我没有停在 Demo 层。我的增量主要有三点：
第一，用真实制度文档构建了自己的评估集；第二，针对流程类问题做了切分和
混合检索优化；第三，沉淀了失败样本分析和回归脚本。面试时我也可以具体展开
哪几类问题最容易失败，以及我怎么处理。

---

📚 Extended Reading（扩展阅读）

• 简历撰写指南
• 秋招完整攻略
• 大厂真实面经
• 开发岗专项题
• 算法岗专项题
• Agent 系统题
• Agent Memory 完整指南
• 12-Factor Agent 架构

---

✅ 最终自检清单

每个项目至少准备这 8 个问题：

• 一句话说清楚项目解决什么问题。
• 画得出系统架构和数据流。
• 说得清楚你负责的模块。
• 说得清楚最难的技术问题。
• 至少有 2 个可信指标。
• 至少有 1 个失败案例。
• 能讲算法岗版本和开发岗版本。
• 能回答“如果上线到生产环境，你还缺什么”。