--- type: 求职指南 status: 已发布 level: 入门 topic: - 面试求职 - 项目实战 - Agent --- # 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 个关键词 ```text 场景清楚、目标明确、架构可画、难点具体、指标可信、复盘真实 ``` 只要缺一个，面试官就会觉得项目不够扎实。 ### 4. 项目闭环六步法 准备项目故事时，不要只背 STAR 四段，而要提前回答六个闭环问题： ```text 为什么要做？ -> 不做会怎样？ -> 为什么选这个方法？ -> 为什么不是其他方法？ -> 怎么验证真的有效？ -> 为什么收益能落到业务或研究价值上？ ``` 这六个问题能把项目从“我用了某个框架”拉回“我定义并解决了一个真实问题”。面试时至少覆盖其中四个，项目可信度会明显提高。 | 闭环问题 | 面试官想判断什么 | Agent 项目回答示例 | |:---|:---|:---| | 为什么要做 | 问题定义能力 | “客服重复回答制度问题，人工处理成本高” | | 不做会怎样 | 业务或研究价值 | “流程类问题仍依赖人工，响应慢且不可规模化” | | 为什么选这个方法 | 技术判断力 | “复杂问题需要状态管理和工具调用，所以用 LangGraph 而不是单轮 prompt” | | 为什么不是其他方法 | 取舍能力 | “Dify 适合快速验证，但底层评估和状态机控制不够可定制” | | 怎么验证有效 | 指标意识 | “用 300 条 QA 集同时看 Recall@5、引用准确率和人工抽检” | | 收益如何落地 | 结果闭环 | “P95 延迟下降、工具调用成功率提升、失败样本可持续回归” | --- ## 🔍 Deep Understanding（深入理解） ### 四档项目讲法 #### 30 秒版本：用于“简单介绍一个项目” ```text 我做的是一个企业知识库 RAG Agent，目标是让员工能用自然语言查询制度和流程。 系统基于 FastAPI、Milvus 和 LangGraph，包含文档解析、混合检索、rerank、 引用溯源和评估集回归。我主要负责检索与评估模块，通过混合检索和重排把 Recall@5 从 68% 提升到 84%，并接入失败案例分析来持续优化。 ``` 结构： ```text 项目是什么 + 为什么做 + 技术栈 + 我的贡献 + 结果 ``` #### 2 分钟版本：用于项目主线讲述 ```text 背景上，这个项目来自企业内部知识库场景，痛点是制度文档多、人工客服重复回答、 普通关键词搜索很难处理流程类问题。 目标上，我定义了两个核心指标：检索 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 注入、权限控制、敏感信息、工具白名单 | ### 算法岗讲述重点 算法岗要突出“实验设计和可验证提升”。 推荐结构： ```text 问题定义 -> baseline -> 方法改进 -> 数据集 -> 指标 -> 消融实验 -> 失败分析 ``` 示例： ```text 我关注的是多跳问答场景下 RAG 召回不足的问题。baseline 是 BM25、dense retrieval 和 GraphRAG。我发现 dense retrieval 对实体精确匹配不稳定， GraphRAG 在小规模数据上构图成本较高，所以设计了 query decomposition + hybrid retrieval + reranker 的组合策略。实验集是 300 条人工标注问题， 最终 Recall@5 从 68% 提升到 84%。消融实验显示 reranker 贡献约 7 个点， query decomposition 对多跳问题贡献更明显。 ``` ### 开发岗讲述重点 开发岗要突出“系统可用性和工程闭环”。 推荐结构： ```text 业务场景 -> 系统架构 -> 核心模块 -> 异常处理 -> 性能优化 -> 部署监控 -> 业务结果 ``` 示例： ```text 我把系统拆成文档处理、检索服务、Agent 编排、评估回归和日志监控五个模块。 线上最常见的问题不是模型答错，而是工具参数错误、检索为空和上下文过长。 所以我加入了工具 schema 校验、fallback 检索、上下文裁剪和日志 trace。 这些机制让工具调用成功率提升到 94%，P95 延迟从 4.8s 降到 1.6s。 ``` ### 面试追问地图 | 面试官追问 | 想考什么 | 回答重点 | |:---|:---|:---| | 你为什么用 LangGraph？ | 框架理解 | 状态机、循环控制、人审节点、可观测性 | | 为什么不用纯 prompt？ | Agent 边界 | 任务需要工具调用、状态管理、多步规划 | | 指标怎么定义？ | 评估意识 | 测试集、指标、人工抽检、失败样本 | | 幻觉怎么处理？ | 可靠性 | 引用溯源、拒答策略、答案校验 | | 工具调用失败怎么办？ | 工程能力 | schema 校验、重试、fallback、日志 | | 如果用户量扩大 10 倍？ | 系统设计 | 缓存、异步队列、限流、模型路由 | | 如果数据有权限？ | 安全意识 | ACL、租户隔离、工具白名单、审计日志 | ### 失败案例要主动准备 优秀的项目讲述一定包含失败案例。不要只讲“我做得很好”，要讲“我怎么发现问题并修掉”。 可准备三类失败： 1. **技术失败**：检索不准、工具调用错、上下文过长、模型幻觉。 2. **工程失败**：延迟太高、成本超预算、日志不可排查。 3. **产品失败**：用户问题和测试集不一致，Demo 好看但真实使用差。 失败案例模板： ```text 最开始我以为问题出在 prompt，但看 trace 后发现 70% 的错误来自检索阶段。 具体表现是用户问流程类问题时，向量检索只召回了定义文档，没有召回操作步骤。 我后来把文档切分从固定 token 改成章节级切分，并加入 BM25 补充实体匹配， 这个改动让流程类问题 Recall@5 提升了 13 个点。 ``` --- ## 💻 Code Examples（代码示例） ### 环境说明 - Python 版本：Python 3.10+ - 依赖：仅使用标准库 - `requirements.txt`：见 `docs/04-interview/examples/requirements.txt` ### 运行方式 ```bash cd AgentGuide python docs/04-interview/examples/resume_storytelling_check.py --mode story ``` ### 你可以用它检查什么 脚本会检查项目讲述是否包含： - 背景：为什么做这个项目。 - 任务：目标和评价指标是什么。 - 行动：你做了什么技术动作。 - 结果：指标、产物或业务价值。 - 复盘：失败案例、取舍或下一步。 如果输出里提示缺少 `result`，说明你的故事很可能停留在“我做了一个系统”，但没有证明它有效。 --- ## 🎯 Interview Questions（面试中如何考） ### Q1：请你用 2 分钟介绍一个最有代表性的 Agent 项目 回答结构： ```text 背景 -> 目标 -> 架构 -> 我的贡献 -> 指标 -> 复盘 ``` 不要上来就说“我用了 LangChain、Milvus、FastAPI”。先说问题，再说技术。 ### Q2：这个项目最大的技术难点是什么？ 推荐答法： ```text 最大的难点不是把链路跑通，而是让结果可评估、可迭代。 最初 Demo 能回答，但不知道哪里好哪里坏。所以我先构建测试集， 再拆分 Recall@5、引用准确率、答案相关性三个指标，最后根据失败样本 反推切分、召回和 rerank 策略。 ``` ### Q3：如果重新做一遍，你会怎么改？ 回答要体现成长： - 数据侧：扩大评估集，加入真实用户问题。 - 架构侧：把 Agent 状态、工具日志、评估结果统一 trace。 - 模型侧：根据任务类型做模型路由，控制成本。 - 安全侧：加入权限过滤、prompt 注入检测和敏感信息脱敏。 ### Q4：你如何证明这个 Agent 比普通 RAG 更好？ 回答思路： 1. 说明普通 RAG 的 baseline。 2. 说明 Agent 增加了什么能力。 3. 用分任务指标证明增益。 ```text 我不会直接说 Agent 更高级，而是按任务类型对比。对于简单定义类问题， 普通 RAG 和 Agent 差距不大；但对于需要多步查询、工具计算、条件判断的问题， Agent 的任务完成率更高。我的测试集中多跳任务完成率从 61% 提升到 78%， 代价是平均响应时间增加约 0.8s，所以我只在复杂问题路由到 Agent。 ``` ### Q5：如果面试官质疑项目太像教程怎么办？ 回答重点： - 承认基础框架来自公开资料。 - 强调你做了自己的场景适配、数据集、指标和失败分析。 - 展示你不只是跑通 Demo，而是做了可复现改进。 ```text 基础链路确实参考了公开教程，但我没有停在 Demo 层。我的增量主要有三点： 第一，用真实制度文档构建了自己的评估集；第二，针对流程类问题做了切分和 混合检索优化；第三，沉淀了失败样本分析和回归脚本。面试时我也可以具体展开 哪几类问题最容易失败，以及我怎么处理。 ``` --- ## 📚 Extended Reading（扩展阅读） - [简历撰写指南](./20-resume-guide.md) - [秋招完整攻略](./08-job-hunting-guide.md) - [大厂真实面经](./12-company-interview-cases.md) - [开发岗专项题](./06-development-specialized.md) - [算法岗专项题](./05-algorithm-specialized.md) - [Agent 系统题](./03-agent-questions.md) - [Agent Memory 完整指南](../02-tech-stack/15-agent-memory.md) - [12-Factor Agent 架构](../02-tech-stack/12-factor-agent-architecture.md) --- ## ✅ 最终自检清单 每个项目至少准备这 8 个问题： - 一句话说清楚项目解决什么问题。 - 画得出系统架构和数据流。 - 说得清楚你负责的模块。 - 说得清楚最难的技术问题。 - 至少有 2 个可信指标。 - 至少有 1 个失败案例。 - 能讲算法岗版本和开发岗版本。 - 能回答“如果上线到生产环境，你还缺什么”。