AI Agent 项目简历撰写指南
本指南面向准备投递 AI Agent / LLM 应用 / RAG / 智能客服等相关岗位的求职者,尤其适合第一次写技术简历或第一次把 Agent 项目写进简历的人。
文中模板、句式与模块描述均可直接复制,再替换为你的真实数据、公司脱敏名与技术名词。
使用方式建议:
- 先通读「总原则」与「常见简历问题诊断」,建立标准。
- 按你的主语言(Python / Java / Go)复制「项目经历模板」,填数字与职责。
- 从「各模块描述示例」里挑选与你项目相符的句子,拼进「核心职责 / 技术亮点」。
- 对照「技能清单写法」整理一页纸技能区,最后做一遍「三问自检」(见文末)。
1. 简历撰写总原则
1.1 STAR 法则在简历中的应用
STAR 是面试常用的表达框架:
| 字母 | 英文 | 含义 |
|---|---|---|
| S | Situation | 情境:业务背景、用户是谁、数据/流量规模 |
| T | Task | 任务:要达成的目标、要解决的矛盾(延迟、成本、准确率等) |
| A | Action | 行动:你具体做了什么技术决策与实现 |
| R | Result | 结果:可验证的指标、上线效果、复盘结论 |
简历与面试的区别:
- 面试可以按 STAR 慢慢讲「当时团队情况是……」。
- 简历篇幅极短,通常把 STAR 压缩成 1~3 句话,不出现「STAR」字样,也不写小说式前因后果。
在简历里的推荐压缩方式:
| STAR 要素 | 简历里怎么写 | 劣质写法 |
|---|---|---|
| S | 半句到一句:场景 + 规模(用户/请求量/文档量) | 「做了一个系统」 |
| T | 嵌入动词:为降低/为提升/为满足 SLA | 「负责开发」 |
| A | 关键技术名 + 你的动作(设计/实现/推动/排障) | 「使用各种技术」 |
| R | 数字或前后对比 | 「效果很好」「显著提升」 |
万能句式(可直接套用):
在 [场景与规模] 下,为 [目标指标],采用 [方案 A + 关键技术名],[你本人主导的动作],最终实现 [量化结果 / 明确对比]。在 [场景与规模] 下,为 [目标指标],采用 [方案 A + 关键技术名],[你本人主导的动作],最终实现 [量化结果 / 明确对比]。再给一个「一条 bullet 里塞满 STAR」的范例:
差:负责 RAG 模块,使用了向量数据库。
好:在日均 1 万+ 问答请求的内部知识库场景下,为降低幻觉与尾延迟,采用混合检索(向量 + BM25)+ Cross-Encoder 重排,并落地 Redis 热点缓存与批量向量化配置,将 P95 端到端延迟从 800ms 降至 320ms,人工抽检回答准确率从 72% 提升至 86%。差:负责 RAG 模块,使用了向量数据库。
好:在日均 1 万+ 问答请求的内部知识库场景下,为降低幻觉与尾延迟,采用混合检索(向量 + BM25)+ Cross-Encoder 重排,并落地 Redis 热点缓存与批量向量化配置,将 P95 端到端延迟从 800ms 降至 320ms,人工抽检回答准确率从 72% 提升至 86%。多写几条时的节奏:第一条偏「整体职责与结果」,后面几条分别写「编排 / RAG / 记忆 / 工具 / 观测」中的深度点,避免每条都是同一种句式开头。
1.2 数字量化的重要性
面试官默认:没有数字 ≈ 没做过、或记不清、或不敢验证。
量化不必全是「百万 QPS」,以下都算有效数字(按你真实能拿到的数据选用):
| 类别 | 可写内容 | 备注 |
|---|---|---|
| 性能 | QPS、RPS、P95/P99 延迟、首字延迟(TTFT)、单次请求成本 | 压测结果、监控截图可备查 |
| 质量 | 准确率、召回率、F1、MRR、nDCG、用户评分、bad case 占比 | 离线评测集要写清规模 |
| 规模 | 文档条数、向量维度、索引分片、日活、会话轮次、工具调用次数 | 体现你处理过真实复杂度 |
| 效率与成本 | Token 消耗下降 %、GPU 占用、人力节省、迭代周期缩短 | Agent 岗很吃香 |
| 稳定性 | 可用性 99.X%、错误率、熔断次数、事故复盘后的改进 | 偏工程岗必写 |
若暂时没有线上指标,可以诚实写:
- 「在自建 200 条问答集上,F1 从 0.61 → 0.79」;
- 「压测单机 X req/s 时 P95 Y ms(环境:……)」。
避免虚构业务数据;面试追问时说不清会扣分。
1.3 技术深度 > 广度
广度:一行里写「会 Python、会 LangChain、会 Milvus、会 K8s」——读者无法区分你和「看过教程的人」。
深度:用 2~3 个 bullet 写清「问题 → 你的方案 → 为何不选更简单的做法 → 结果」。
示例对比:
浅:熟悉 RAG 与 Agent 开发。
深:针对多跳问答中「检索漂移」问题,对比仅向量检索与 HyDE + 混合检索,在业务测试集上选择后者,Recall@5 从 0.58 提升至 0.81,并记录失败样本用于周度迭代。浅:熟悉 RAG 与 Agent 开发。
深:针对多跳问答中「检索漂移」问题,对比仅向量检索与 HyDE + 混合检索,在业务测试集上选择后者,Recall@5 从 0.58 提升至 0.81,并记录失败样本用于周度迭代。简历结构建议:
- 技能清单 / 技术栈一行:体现广度(与 JD 关键词对齐)。
- 项目经历 bullet:体现深度(每个点尽量有「方案 + 结果」)。
1.4 避免的常见错误
| 错误类型 | 说明 | 改进方向 |
|---|---|---|
| 泛泛动词 | 「参与」「协助」「熟悉」无下文 | 改为「设计并实现」「将 X 从 A 优化到 B」「推动上线」 |
| 只堆名词 | 只写技术栈,不写动作 | 每个技术栈词后面跟「用来解决了什么问题」 |
| 抢功 | 把团队成果全写成「我」 | 写清「在 X 人团队中负责 Y 子系统」,面试可自洽 |
| 无关堆砌 | 大段传统 CRUD,与 Agent 无关 | Agent 岗优先:编排、工具、RAG、评测、成本、延迟、可观测 |
| 泄密 | 写真实客户名、未公开数据 | 用「某金融客户」「Top3 互联网」;数字用区间或同比 |
| 口语与 emoji | 「很厉害」「🔥」 | 全文书面语,专业、克制 |
| 过长段落 | HR 10 秒扫一份简历 | 多用短句、分号列表;核心数字加粗(若投递系统支持) |
2. 技术栈展示
原则:按「语言/运行时 → Web 框架 → Agent/模型 → 检索与数据 → 消息与任务 → 可观测与部署」分组,每组一行或一行半;不要把 30 个词无结构地堆成一行。
三个「不要」:
- 不要写「精通」除非你真能经得住深挖。
- 不要写已废弃或自己只复制过 Demo 的版本号(如乱写 Python 2.7)。
- JD 里强调的词,往前放、写全拼(如对方写 LangGraph,你就别只写 LC)。
2.1 Python 版本的技术栈写法
分组模板(复制后改词):
语言与运行时:Python 3.11+(类型注解 / asyncio)
Web 与 API:FastAPI、Uvicorn、Pydantic v2
Agent 与编排:LangChain、LangGraph(或 AutoGen、自研状态机)
模型与网关:OpenAI 兼容 API、vLLM / Ollama(按需)、提示词与工具 Schema 治理
检索与向量:Milvus / Qdrant / Weaviate(三选一写实)、Elasticsearch(BM25)、混合检索、bge-reranker 等重排模型
数据与缓存:PostgreSQL、Redis(会话 / 缓存 / 限流计数)
异步与消息(如有):Celery、Kafka、RabbitMQ
可观测:OpenTelemetry、LangSmith 或 Langfuse、结构化日志
部署与工程:Docker、Kubernetes、GitHub Actions / GitLab CI语言与运行时:Python 3.11+(类型注解 / asyncio)
Web 与 API:FastAPI、Uvicorn、Pydantic v2
Agent 与编排:LangChain、LangGraph(或 AutoGen、自研状态机)
模型与网关:OpenAI 兼容 API、vLLM / Ollama(按需)、提示词与工具 Schema 治理
检索与向量:Milvus / Qdrant / Weaviate(三选一写实)、Elasticsearch(BM25)、混合检索、bge-reranker 等重排模型
数据与缓存:PostgreSQL、Redis(会话 / 缓存 / 限流计数)
异步与消息(如有):Celery、Kafka、RabbitMQ
可观测:OpenTelemetry、LangSmith 或 Langfuse、结构化日志
部署与工程:Docker、Kubernetes、GitHub Actions / GitLab CI简历「一句话技术栈」(放摘要或项目标题下):
Python · FastAPI · LangGraph · RAG(Milvus + ES 混合检索)· Redis · PostgreSQL · Docker · OTelPython · FastAPI · LangGraph · RAG(Milvus + ES 混合检索)· Redis · PostgreSQL · Docker · OTel小白可加的诚实备注(可选,一行):
个人项目:完整链路在本地/云主机跑通,使用自建评测集与离线指标(无线上流量数据)。个人项目:完整链路在本地/云主机跑通,使用自建评测集与离线指标(无线上流量数据)。2.2 Java 版本的技术栈写法
语言:Java 17+(Record、虚拟线程按实写)
框架:Spring Boot 3、Spring WebFlux 或 Spring MVC
集成与韧性:OpenFeign、Resilience4j(熔断 / 限流 / 重试)
检索:Elasticsearch Java API、Milvus/Qdrant 客户端(或 HTTP 调用向量服务)
数据:Spring Data JPA / MyBatis、PostgreSQL、Redis(Lettuce)
消息:Kafka / RocketMQ(如有)
可观测:Micrometer、Prometheus、Grafana
构建与部署:Maven / Gradle、Docker、Kubernetes语言:Java 17+(Record、虚拟线程按实写)
框架:Spring Boot 3、Spring WebFlux 或 Spring MVC
集成与韧性:OpenFeign、Resilience4j(熔断 / 限流 / 重试)
检索:Elasticsearch Java API、Milvus/Qdrant 客户端(或 HTTP 调用向量服务)
数据:Spring Data JPA / MyBatis、PostgreSQL、Redis(Lettuce)
消息:Kafka / RocketMQ(如有)
可观测:Micrometer、Prometheus、Grafana
构建与部署:Maven / Gradle、Docker、Kubernetes与 Python Agent 服务协作时,务必写清边界(避免面试穿帮):
Java 侧负责会话、鉴权、网关、B 端编排与检索结果合并;Python 侧负责 LangGraph 与重模型推理(如实调整)。Java 侧负责会话、鉴权、网关、B 端编排与检索结果合并;Python 侧负责 LangGraph 与重模型推理(如实调整)。一句话技术栈:
Java 17 · Spring Boot 3 · WebFlux/SSE · OpenFeign · Resilience4j · Elasticsearch · Redis · PostgreSQL · K8sJava 17 · Spring Boot 3 · WebFlux/SSE · OpenFeign · Resilience4j · Elasticsearch · Redis · PostgreSQL · K8s2.3 Go 版本的技术栈写法
语言:Go 1.22+
Web 与 RPC:Gin / Fiber / Echo、gRPC、protobuf
Agent 相关:高性能 LLM 代理、流式 chunk 转发、工具执行器、连接池与背压
检索与存储:Redis(go-redis)、PostgreSQL(pgx)、Elasticsearch 客户端
可观测:OpenTelemetry Go、Prometheus、Grafana、zap / slog 日志
部署:Docker、Kubernetes、健康检查与优雅退出语言:Go 1.22+
Web 与 RPC:Gin / Fiber / Echo、gRPC、protobuf
Agent 相关:高性能 LLM 代理、流式 chunk 转发、工具执行器、连接池与背压
检索与存储:Redis(go-redis)、PostgreSQL(pgx)、Elasticsearch 客户端
可观测:OpenTelemetry Go、Prometheus、Grafana、zap / slog 日志
部署:Docker、Kubernetes、健康检查与优雅退出一句话技术栈:
Go · Gin · gRPC · LLM 网关与流式代理 · Redis · PostgreSQL · OTel · Prometheus · K8sGo · Gin · gRPC · LLM 网关与流式代理 · Redis · PostgreSQL · OTel · Prometheus · K8s3. 项目经历模板(三个版本)
每个版本都建议包含:项目名称、项目描述、技术栈、核心职责、技术亮点、项目成果。
按需补充:起止时间、你的角色(独立 / 核心开发 / 成员)、团队规模、是否已上线。
3.1 Python 版项目经历(完整可复制模板)
项目名称:企业级 AI Agent 智能助手平台
项目描述:
基于大模型的企业级智能客服与知识助手系统,支持多轮对话、知识库检索、工具调用与人工兜底;
面向内部员工或外部客户,对接企业文档与工单系统,满足合规与审计要求。
技术栈:
Python, FastAPI, LangChain, LangGraph, Milvus, Redis, PostgreSQL
核心职责:
1. 设计并实现 Agent 多步编排与状态持久化,支持工具失败重试与人工介入节点,日均稳定处理 X 万轮对话。
2. 搭建 RAG 流水线:文档解析、分块、向量化与增量更新,并实现混合检索 + 重排序,将 Top-5 命中率从 X% 提升至 Y%。
3. 落地会话级记忆与业务记忆分层策略,结合 Redis TTL 与 PostgreSQL 归档,将会话上下文成本降低约 Z%。
4. 与模型网关联调流式输出与限流熔断,将端到端 P95 延迟控制在 X ms 内。
技术亮点:
1. 使用 LangGraph(或自研状态机)显式建模「规划 → 工具 → 反思 → 输出」,配置循环与步数上限,避免无限 ReAct。
2. RAG 侧采用「向量 + 关键词」混合检索与 Cross-Encoder 重排,对 PDF 表格与 FAQ 做结构化解析与路由。
3. 建立评测集与线上 bad case 回流机制,固定节奏发布提示词与检索参数版本。
项目成果:
- 响应准确率(人工抽检)从 XX% 提升至 XX%。
- P95 检索延迟从 XX ms 降至 XX ms;核心接口可用性达 XX%。
- 工具调用成功率从 XX% 提升至 XX%;平均对话轮次 X 轮,用户满意度 X/5。项目名称:企业级 AI Agent 智能助手平台
项目描述:
基于大模型的企业级智能客服与知识助手系统,支持多轮对话、知识库检索、工具调用与人工兜底;
面向内部员工或外部客户,对接企业文档与工单系统,满足合规与审计要求。
技术栈:
Python, FastAPI, LangChain, LangGraph, Milvus, Redis, PostgreSQL
核心职责:
1. 设计并实现 Agent 多步编排与状态持久化,支持工具失败重试与人工介入节点,日均稳定处理 X 万轮对话。
2. 搭建 RAG 流水线:文档解析、分块、向量化与增量更新,并实现混合检索 + 重排序,将 Top-5 命中率从 X% 提升至 Y%。
3. 落地会话级记忆与业务记忆分层策略,结合 Redis TTL 与 PostgreSQL 归档,将会话上下文成本降低约 Z%。
4. 与模型网关联调流式输出与限流熔断,将端到端 P95 延迟控制在 X ms 内。
技术亮点:
1. 使用 LangGraph(或自研状态机)显式建模「规划 → 工具 → 反思 → 输出」,配置循环与步数上限,避免无限 ReAct。
2. RAG 侧采用「向量 + 关键词」混合检索与 Cross-Encoder 重排,对 PDF 表格与 FAQ 做结构化解析与路由。
3. 建立评测集与线上 bad case 回流机制,固定节奏发布提示词与检索参数版本。
项目成果:
- 响应准确率(人工抽检)从 XX% 提升至 XX%。
- P95 检索延迟从 XX ms 降至 XX ms;核心接口可用性达 XX%。
- 工具调用成功率从 XX% 提升至 XX%;平均对话轮次 X 轮,用户满意度 X/5。3.2 Java 版项目经历(完整可复制模板)
项目名称:企业级智能问答与 Agent 编排服务平台
项目描述:
基于 Spring Boot 的企业级 LLM 应用平台,提供同步/流式问答、会话管理、工具编排及与企业 SSO、审计日志集成;
检索层对接 Elasticsearch 与向量检索服务,支撑知识库与工单检索场景。
技术栈:
Java 17, Spring Boot 3, Spring WebFlux, OpenFeign, Resilience4j, Elasticsearch, Redis, PostgreSQL, Kafka(可选)
核心职责:
1. 设计并实现模型网关调用层:流式 SSE、超时重试、熔断与配额,保障大促期间核心链路可用性达 X%。
2. 封装工具执行与权限校验(角色、数据域),与内部 CRM/工单 API 集成;工具失败时降级为纯 RAG 回答。
3. 主导检索策略在 Java 侧的编排:查询改写请求发送、结果合并与重排结果融合,将业务相关问题的 Top-3 命中率提升 X%。
4. 使用 Micrometer + Prometheus 搭建核心指标大盘,缩短平均故障定位时间。
技术亮点:
1. WebFlux + SSE 实现低延迟流式体验,线程池隔离与背压策略避免阻塞扩大。
2. Resilience4j 实现按租户限流与多模型供应商切换,单点故障时自动降级备用模型。
3. 与向量/Agent 服务通过 gRPC/HTTP 明确契约与 SLA,前后端链路 Trace ID 贯通。
项目成果:
- 流式首字延迟(TTFT)P95 从 XX ms 降至 XX ms。
- 生产环境重大事故从 X 次/季度降至 0;检索相关客诉下降 XX%。
- 日均请求量 X 万,峰值 QPS X,错误率 < X%。项目名称:企业级智能问答与 Agent 编排服务平台
项目描述:
基于 Spring Boot 的企业级 LLM 应用平台,提供同步/流式问答、会话管理、工具编排及与企业 SSO、审计日志集成;
检索层对接 Elasticsearch 与向量检索服务,支撑知识库与工单检索场景。
技术栈:
Java 17, Spring Boot 3, Spring WebFlux, OpenFeign, Resilience4j, Elasticsearch, Redis, PostgreSQL, Kafka(可选)
核心职责:
1. 设计并实现模型网关调用层:流式 SSE、超时重试、熔断与配额,保障大促期间核心链路可用性达 X%。
2. 封装工具执行与权限校验(角色、数据域),与内部 CRM/工单 API 集成;工具失败时降级为纯 RAG 回答。
3. 主导检索策略在 Java 侧的编排:查询改写请求发送、结果合并与重排结果融合,将业务相关问题的 Top-3 命中率提升 X%。
4. 使用 Micrometer + Prometheus 搭建核心指标大盘,缩短平均故障定位时间。
技术亮点:
1. WebFlux + SSE 实现低延迟流式体验,线程池隔离与背压策略避免阻塞扩大。
2. Resilience4j 实现按租户限流与多模型供应商切换,单点故障时自动降级备用模型。
3. 与向量/Agent 服务通过 gRPC/HTTP 明确契约与 SLA,前后端链路 Trace ID 贯通。
项目成果:
- 流式首字延迟(TTFT)P95 从 XX ms 降至 XX ms。
- 生产环境重大事故从 X 次/季度降至 0;检索相关客诉下降 XX%。
- 日均请求量 X 万,峰值 QPS X,错误率 < X%。3.3 Go 版项目经历(完整可复制模板)
项目名称:高并发 LLM 网关与 Agent 执行引擎
项目描述:
面向高 QPS 场景的 LLM 代理与工具执行服务,负责请求路由、流式转发、计费与限流;
下游对接多家模型供应商与自托管推理集群,上游对接业务方与统一鉴权。
技术栈:
Go, Gin(或 Fiber), gRPC, Redis, PostgreSQL, OpenTelemetry, Prometheus, Kubernetes
核心职责:
1. 实现高性能流式代理:chunk 转发、连接复用、优雅关闭,单机压测支撑 X k QPS(写明环境)。
2. 设计工具执行沙箱与超时控制,隔离用户输入与下游 HTTP 调用,降低 SSRF 与资源耗尽风险。
3. 基于 Redis 的令牌桶与滑动窗口限流,按租户与模型维度配额,保障核心客户 SLA。
4. 全链路 Trace ID 贯通网关、工具与向量检索,可观测数据在 P95 X ms 内完成上报。
技术亮点:
1. 连接池与内存分配优化,降低 GC 压力与尾延迟。
2. 多模型路由策略:成本优先 / 延迟优先 / 质量优先可配置,失败自动切换。
3. 与 Python Agent 编排服务职责分离:Go 负责 IO 密集与网关,复杂编排走独立服务(按实写)。
项目成果:
- 网关层 P99 延迟 XX ms;错误率 X%。
- 通过限流与路由优化,模型调用成本下降约 XX%。
- 支撑 X 个租户、日均 X 亿 token(或日均 X 万次请求)。项目名称:高并发 LLM 网关与 Agent 执行引擎
项目描述:
面向高 QPS 场景的 LLM 代理与工具执行服务,负责请求路由、流式转发、计费与限流;
下游对接多家模型供应商与自托管推理集群,上游对接业务方与统一鉴权。
技术栈:
Go, Gin(或 Fiber), gRPC, Redis, PostgreSQL, OpenTelemetry, Prometheus, Kubernetes
核心职责:
1. 实现高性能流式代理:chunk 转发、连接复用、优雅关闭,单机压测支撑 X k QPS(写明环境)。
2. 设计工具执行沙箱与超时控制,隔离用户输入与下游 HTTP 调用,降低 SSRF 与资源耗尽风险。
3. 基于 Redis 的令牌桶与滑动窗口限流,按租户与模型维度配额,保障核心客户 SLA。
4. 全链路 Trace ID 贯通网关、工具与向量检索,可观测数据在 P95 X ms 内完成上报。
技术亮点:
1. 连接池与内存分配优化,降低 GC 压力与尾延迟。
2. 多模型路由策略:成本优先 / 延迟优先 / 质量优先可配置,失败自动切换。
3. 与 Python Agent 编排服务职责分离:Go 负责 IO 密集与网关,复杂编排走独立服务(按实写)。
项目成果:
- 网关层 P99 延迟 XX ms;错误率 X%。
- 通过限流与路由优化,模型调用成本下降约 XX%。
- 支撑 X 个租户、日均 X 亿 token(或日均 X 万次请求)。4. 各模块的简历描述示例
以下句子可按需拆分、合并、改数字。建议每个模块选 1~2 条写进简历,避免堆砌。
4.1 Agent 编排模块怎么写
能力点关键词:状态机、LangGraph、ReAct、规划、人机协同、防死循环、检查点。
可直接使用的描述(多选):
- 基于 LangGraph / 自研有向图将业务拆成「意图识别 → 规划 → 工具调用 → 反思 → 最终回复」多节点流程,状态持久化至 Redis/DB,支持断点续跑与人工接管。
- 配置最大步数、最大工具调用次数、重复调用检测,将异常会话占比从 X% 降至 Y%。
- 实现并行工具调用的结果合并与冲突消解,平均完成任务步数减少 X 步,任务完成率提升 X%。
- 对敏感操作(下单、改库)设计确认节点与二次校验,满足业务风控要求。
- 将 Prompt 版本与编排版本绑定发布,支持灰度与快速回滚,缩短故障恢复时间至 X 分钟内。
4.2 RAG 检索模块怎么写
能力点关键词:解析、分块、Embedding、混合检索、重排、增量索引、评测。
可直接使用的描述:
- 搭建解析 → 清洗 → 分块 → 向量化 → 索引全链路,支持 PDF/Word/HTML/表格等格式,全量索引 X 万篇、增量更新延迟 < X 分钟。
- 采用稠密向量检索 + BM25(Elasticsearch)混合召回,并用 Cross-Encoder / 轻量重排模型精排,Recall@5 从 X 提升至 Y(Z 条标注集)。
- 针对短问句、指代、多跳问题引入查询改写 / HyDE / 子查询分解,「检索为空」类 bad case 下降 X%。
- 建立文档质量过滤(重复、空页、乱码)与切块策略实验(固定长度 / 语义分块),离线指标与线上一致性每月对齐。
- 对权限与多租户做 collection/namespace 隔离,检索仅返回用户可见文档块。
4.3 记忆系统怎么写
能力点关键词:短期记忆、长期记忆、摘要、滑动窗口、TTL、合规。
可直接使用的描述:
- 设计会话级短期记忆(Redis)+ 用户级长期偏好(PostgreSQL)分层存储,关键字段满足审计与追溯。
- 在上下文长度限制下,采用摘要压缩 + 滑动窗口策略,平均每轮 token 消耗降低 X%,多轮主题连贯性经人工抽检达标。
- 对 PII 做脱敏与可删除设计(用户行使被遗忘权时可清理),满足合规要求。
- 实现记忆召回策略(仅最近 K 轮 / 语义检索历史摘要),避免无关历史干扰当前回答。
4.4 工具系统怎么写
能力点关键词:JSON Schema、OpenAPI、权限、限流、超时、幂等、降级。
可直接使用的描述:
- 基于 OpenAPI / JSON Schema 统一工具描述与入参校验,对接内部 HTTP API、只读 SQL、检索服务。
- 为工具调用增加鉴权、租户隔离、超时、重试与幂等键,失败时自动降级为纯模型回答或固定话术,工具成功率从 X% 提升至 Y%。
- 搭建工具调用全量日志与请求回放,支撑 bad case 复现与提示词迭代。
- 对高风险工具采用「模型建议 + 后端二次规则校验」双保险,拦截 X% 越权请求。
4.5 模型路由与容错怎么写
能力点关键词:多供应商、主备、熔断、429、退避、缓存、成本。
可直接使用的描述:
- 实现主备模型与多供应商路由,按成本 / 延迟 / 能力配置策略,故障时自动切换,核心链路可用性 X%。
- 对 429、5xx、超时实施指数退避 + 熔断 + 舱壁隔离,并结合热点问答缓存削减峰值依赖。
- 流式场景处理客户端断开、中途取消,减少无效计费与僵尸连接数 X%。
- 建立按租户与按模型的成本仪表盘,推动小模型兜底 + 大模型精修策略,月度成本下降 X%。
4.6 ETL 流水线怎么写
能力点关键词:Airflow、队列、批处理、embedding 成本、数据质量。
可直接使用的描述:
- 使用 Airflow / Dagster / 自研 Cron + 队列调度文档拉取、清洗、向量化,支持失败重试、死信队列与告警。
- 对大文件分片与批量 embedding 调用,将单位文档处理成本降低 X%,全量重建时间从 X 小时降至 Y 小时。
- 建立数据质量规则(最小长度、编码检测、重复块过滤),脏数据进入索引前拦截率 X%。
- 与业务方约定增量与全量触发条件,版本化索引可回滚。
4.7 全链路追踪怎么写
能力点关键词:OpenTelemetry、Trace、Span、LangSmith、SLO、告警。
可直接使用的描述:
- 接入 OpenTelemetry,为请求生成 Trace ID,贯通网关、Agent、检索、工具、模型调用。
- 在 LangSmith / Langfuse / 自研看板上关联单次对话与评测集条目,bad case 定位时间从 X 分钟缩短至 Y 分钟。
- 定义核心 SLI(P95 延迟、错误率、工具失败率)与 SLO,接入告警与值班流程。
- 对高价值客户开启采样策略与日志脱敏平衡,兼顾可观测与合规。
5. 技能清单写法
目标:让 HR 与面试官在 10 秒内判断「是否匹配 JD」,并给你面试追问入口。
推荐结构(复制后改词):
编程语言:Python(主力)、SQL、Shell
Agent 与 LLM:LangChain、LangGraph、提示词工程、工具调用(OpenAPI/JSON Schema)、简单评测与 bad case 分析
检索与 RAG:Milvus、Elasticsearch、混合检索、重排序、Embedding 模型选型与切块实验
后端:FastAPI、异步 IO、REST/SSE、鉴权与多租户(按实写)
数据:PostgreSQL、Redis、缓存与一致性经验(按实写)
工程化:Docker、CI/CD、单元测试/集成测试、基础 K8s
其他:英语读写(CET-6)、技术博客/开源(如有)编程语言:Python(主力)、SQL、Shell
Agent 与 LLM:LangChain、LangGraph、提示词工程、工具调用(OpenAPI/JSON Schema)、简单评测与 bad case 分析
检索与 RAG:Milvus、Elasticsearch、混合检索、重排序、Embedding 模型选型与切块实验
后端:FastAPI、异步 IO、REST/SSE、鉴权与多租户(按实写)
数据:PostgreSQL、Redis、缓存与一致性经验(按实写)
工程化:Docker、CI/CD、单元测试/集成测试、基础 K8s
其他:英语读写(CET-6)、技术博客/开源(如有)排序技巧:
- JD 出现的关键词往前放(岗位写「LangGraph」就显眼写 LangGraph)。
- 每一行 2~5 个具体词即可,不要一行 20 个。
- 少用「熟悉/了解」;若用,必须跟具体事实:「了解 LoRA,曾用 X 数据集跑通过一次微调实验」。
- 不要单列「ChatGPT」;可写「大模型 API 集成与流式对话」。
- 证书与语言:外企或海外团队可写 CET/雅思/托福;与岗无关可省略。
6. 常见简历问题诊断
每个问题都给出修改前 / 修改后对比。请将示例中的数字替换为你自己的真实或诚实标注过的数据。
问题 1:描述太笼统
| 修改前 | 修改后 |
|---|---|
| 负责公司 AI 项目开发。 | 负责企业知识库问答子系统:基于 FastAPI + Milvus 实现混合检索与重排,覆盖 X 个业务线、Y 万份文档,日均 Z 万次查询。 |
| 参与 RAG 优化。 | 针对检索漂移引入查询改写与 HyDE,在 500 条业务标注集上 Recall@5 从 0.61 提升至 0.79。 |
| 做了 Agent 相关功能。 | 使用 LangGraph 落地「规划-工具-反思」编排,配置步数上限与重复检测,异常会话占比从 8% 降至 2%。 |
问题 2:没有量化数据
| 修改前 | 修改后 |
|---|---|
| 显著降低了延迟。 | 将检索链路 P95 延迟从 650ms 降至 280ms(含 Redis 缓存与批量向量优化)。 |
| 提升了用户满意度。 | 人工抽检满意度从 3.2/5 提升至 4.1/5;工单转人工率下降 18%。 |
| 优化了成本。 | 通过小模型意图分类 + 大模型生成,平均每会话 token 消耗下降 35%(基于 X 条日志采样)。 |
问题 3:技术栈罗列
| 修改前 | 修改后 |
|---|---|
| 使用 Python、LangChain、向量数据库、Redis。 | 使用 Python + LangChain 搭建 Agent;向量检索采用 Milvus HNSW 索引,Redis 缓存热点 query 的检索结果,命中后延迟 < 50ms。 |
| 熟悉各种大模型。 | 对接 Azure OpenAI 与自建 vLLM,经统一网关做流式转发、按租户限流与主备切换。 |
| 会 Docker、K8s、Prometheus。 | 将服务容器化并通过 Helm 部署至 K8s,Prometheus + Grafana 监控 P95 延迟与错误率,告警接入企业微信。 |
问题 4:项目描述像说明文档
| 修改前 | 修改后 |
|---|---|
| 本系统是一个基于大模型的智能问答系统,用户在前台输入问题,系统调用后端,后端检索知识库并返回答案。 | 面向一线客服场景,打通多轮对话与工单检索;本人负责检索与重排,通过混合检索 + Cross-Encoder 将 Top-1 准确率从 52% 提升至 71%,P95 延迟满足 SLA 400ms。 |
| 系统采用微服务架构,模块很多,扩展性好。 | 检索与向量索引独立部署,支持独立扩缩容;本人负责检索服务 SLO(P95 < 300ms),大促期间通过只读副本 + 缓存扛住 3 倍流量。 |
7. 针对不同背景的简历建议
7.1 应届生 / 小白
侧重点:学习能力、完整闭环、诚实、可验证(代码/数据集/实验记录)。
项目数量:1~2 个深挖远好于 5 个浅尝;每个项目能讲清「数据从哪来、指标怎么算、失败怎么改」。
深度来源:课设、毕设、开源贡献、天池/Kaggle、个人 GitHub;写明复现了哪篇/哪个仓库,你的增量是什么。
没有线上数据:明确写「自建 N 条评测集」「离线 F1 / Recall@k」「本地/云主机压测」,不要装成大规模生产。
可写进简历的诚实表述:
应届,在校期间完成基于 LangChain 的 RAG 问答项目:实现文档解析、Milvus 索引与混合检索;
在自建 200 条问答集上 F1 达 0.78,代码与实验记录已开源于 GitHub(可附链接)。应届,在校期间完成基于 LangChain 的 RAG 问答项目:实现文档解析、Milvus 索引与混合检索;
在自建 200 条问答集上 F1 达 0.78,代码与实验记录已开源于 GitHub(可附链接)。避免:空泛「热爱 AI」、罗列十几门网课、虚构大厂实习。
7.2 1~3 年经验
侧重点:ownership、线上结果、协作边界、技术权衡。
每条经历写清:你负责的模块、与谁协作(前端/算法/运维)、上线后的指标。
主动写 1 条与事故、评测、成本、延迟相关的内容,区分度会明显提高。
权衡示例:「在延迟敏感场景放弃重型重排模型,改用轻量双塔 + 规则后处理,P95 达标且 Recall@5 仅降 2 个点,业务接受。」
摘要句模板:
2 年后端经验,近 1 年聚焦 LLM 应用:独立负责检索与评测闭环,推动混合检索与重排上线,
核心业务场景 Top-3 命中率提升 15%,P95 延迟下降 40%。2 年后端经验,近 1 年聚焦 LLM 应用:独立负责检索与评测闭环,推动混合检索与重排上线,
核心业务场景 Top-3 命中率提升 15%,P95 延迟下降 40%。7.3 转行人员
侧重点:可迁移能力、学习路径、项目与目标岗的重叠度。
过去工作翻译成新语境:后端 → 稳定性、性能、接口契约;数据 → ETL、质量、评测集;产品/运营 → 需求拆解、指标体系。
简历上写清投入:例如「6 个月系统学习 + 2 个完整项目」,减少「只培训过」印象。
传统行业项目可压缩为一行背景,篇幅留给 Agent/RAG/网关相关经历。
摘要句模板:
X 年 Java 后端,系统学习 LLM 应用开发并完成生产级 RAG 项目:
负责 Spring 侧网关与检索编排对接,流式链路 P95 达标;自学 Python 评测脚本与提示词迭代,离线指标与线上一致性按月对齐。X 年 Java 后端,系统学习 LLM 应用开发并完成生产级 RAG 项目:
负责 Spring 侧网关与检索编排对接,流式链路 P95 达标;自学 Python 评测脚本与提示词迭代,离线指标与线上一致性按月对齐。结语 · 投递前三问自检
- 这条经历能否在面试里展开讲满 8~10 分钟?(背景、方案、取舍、数据、复盘)
- 简历上的数字是否经得起追问?(口径、采样时间、环境)
- 关键词是否与目标 JD 对齐?(可适当同义替换,但不要造假经历)
好简历 = 真实经历 + 清晰结构 + 可验证结果。祝你求职顺利。
Cao Note