能力对标：简历该突出什么

先说结论：Agent 方向的简历筛选逻辑和传统后端/前端岗位有一个本质区别——这个领域太新，没有「标准履历」这种东西。没有哪家公司的 Title 能直接证明你会做 Agent，学历和证书的信号也被稀释得很厉害。筛简历的人（不管是 HR 还是技术面试官）真正能依赖的信号只有两个：你做过什么项目，以及你能不能把项目里的数字讲清楚。

这一页不讲通用的简历排版技巧（那些任何简历指南都会讲），只讲 Agent 方向特有的部分：什么样的项目描述会被认真对待，什么样的写法会立刻暴露「只看过教程」，以及零相关经验的人怎么补齐短板。岗位侧的能力要求拆解见岗位版图和 JD 清单，这一页解决的是「你已经会了一些东西，怎么把它们写到纸上」。

一、Agent 方向简历的特殊性

项目 > 学历，能量化 > 形容词

2025 年以来 AI 岗位的需求量增长非常快。据 Lightcast 的全球 AI 技能岗位数据，2024 到 2025 年要求 AI 技能的岗位发布量同比增长超过一倍；PwC 的 2025 全球 AI 岗位晴雨表显示，具备 AI 技能的从业者相对同岗位无 AI 技能者有显著的薪资溢价。需求涨得快，供给端的问题是：大量简历长得一模一样——「熟悉 LangChain，做过 RAG 项目，了解 Agent」。当所有人都会写这几个词的时候，这几个词就丧失了区分度。

真正稀缺的信号是生产经验。Stack Overflow 2025 开发者调查显示，超过一半的开发者还没有在工作流里使用 AI Agent。也就是说，一个真的能讲清楚「我做的 Agent 在生产环境里怎么失败过、我怎么发现和修掉的」的候选人，仍然是少数。简历的唯一任务，就是让筛简历的人在 30 秒内确认你属于这少数人。

这带来两条硬规则：

1. 项目的权重压倒一切。一个描述扎实的 Agent 项目（哪怕是自己做的作品集项目），胜过「985 硕士 + 熟悉各种框架」。反过来，如果项目栏写的是空话，学历再好也只能过初筛，过不了技术面。
2. 每个项目必须带数字，数字必须可被追问。写「提升了回答质量」等于没写；写「答案采纳率从 61% 提升到 83%（200 条人工标注的 golden set 上评估）」才是有效信息。面试官一定会追问「这个数怎么测的」，答不上来比不写更糟——它直接说明你不理解 eval，而 eval 素养恰恰是 2026 年招聘方公认的「真做过 LLM 和只看过视频」的分水岭。

面试官在 Agent 简历里找的三个信号

综合近一年的招聘侧讨论，技术面试官扫 Agent 简历时实际在找三样东西：

信号	简历上的体现	反面（暴露没做过）
评估意识	每个项目有明确的指标、测试集规模、评估方法	「效果很好」「准确率高」，无定义无来源
成本意识	提到 token 成本、延迟、模型选型的取舍	全程只有效果，没有一分钱和一秒的考量
失败模式认知	主动写遇到的坑：幻觉、循环调用、工具误用、context 爆炸	项目描述一片光明，像教程复刻

一个反直觉的事实

写「我踩过的坑」比写「我多厉害」更能加分。Agent 系统的难点几乎全部在失败模式上——Agent Loop 死循环、工具返回脏数据、长任务 context 撑爆。一个能具体描述失败和修复过程的候选人，比一个只展示成功结果的候选人可信得多。把「故障与修复」写进项目描述，是这个方向特有的加分项。

二、项目经历写法：STAR 在 Agent 项目上的应用

STAR（Situation / Task / Action / Result）是写项目经历的经典框架，但套在 Agent 项目上需要做一次「翻译」，否则写出来还是流水账：

STAR 要素	传统项目的写法	Agent 项目该写什么
Situation	业务背景、团队规模	业务场景 + 为什么需要 Agent（而不是确定性流程/单次 LLM 调用）
Task	你负责的模块	你负责的部分：规划、工具接入、检索、评估、上线——具体到边界
Action	用了什么技术	架构选型 + 取舍理由（为什么用 ReAct 不用 Plan-and-Execute，为什么自建不用框架）
Result	性能提升、用户量	可量化的效果指标 + 成本/延迟指标 + 失败率的下降

注意 Action 那一行：Agent 项目的 Action 里最值钱的不是「用了 X」，而是「为什么用 X 不用 Y」。选型理由证明你理解权衡，这是工程师和调包侠的分界线。关于常见的架构取舍，可以参考框架选型总览和设计原则。

下面给三个完整的改写案例。数字均为示例，请替换成你自己测出来的真实数字。

案例一：客服机器人

平淡版（典型淘汰写法）：

负责公司客服机器人的开发，使用 LangChain 调用 GPT API，实现了多轮对话功能，提升了客服效率。

问题：没有任何信息增量。「用了 LangChain」「调了 API」「提升了效率」——三句话里没有一个可以被追问的点。

专业版：

背景：电商售后场景，日均 3000+ 咨询，人工客服成本是主要痛点；70% 的咨询集中在退换货、物流查询等 6 类意图。

任务：独立负责对话 Agent 的设计与上线，目标是把 6 类高频意图的自动解决率做到可用水平。

行动：基于 ReAct 模式构建多轮客服 Agent，接入订单查询、物流、退款工单 3 个内部工具（Function Calling）；为控制幻觉，对退款类操作加了人工确认节点（human-in-the-loop）；用 200 条历史对话构建 golden set，以 LLM-as-judge + 人工抽检做回归评估。

结果：意图识别准确率 89%（golden set 上测），6 类意图的人工接管率从 100% 降至 42%，单次对话平均成本控制在 ¥0.08；上线后踩过的最大坑是物流接口超时导致 Agent 重试风暴，通过给工具调用加超时熔断和最大步数限制解决。

点评：这一版每一段都可以追问，而且追问下去只会加分。注意它写进了成本、评估方法和一次真实的故障——三个信号全齐。

案例二：RAG 知识库

平淡版：

搭建了基于向量数据库的企业知识库问答系统，实现了 RAG 检索增强，回答准确率很高。

问题：「准确率很高」是最危险的写法之一。招聘方的经验法则是：写了「实现了 RAG」却给不出任何召回/命中率数字的，基本可以判定只做过 demo——任何认真对待检索质量的人都会留下 recall 指标。RAG 的技术细节见 RAG 组件页。

专业版：

背景：公司内部 2 万+ 篇技术文档，新员工查找信息平均耗时过长；文档格式混杂（Wiki、PDF、Markdown），且持续更新。

任务：负责检索链路的选型与调优（embedding、chunking、rerank），以及问答质量的评估体系。

行动：对比纯向量检索与 BM25 + 向量的混合检索，后者在自建测试集上 recall@10 从 0.71 提升到 0.86；按文档结构做语义切分（而非固定窗口），并加了一层交叉编码器 rerank；建立 150 条「问题-应命中文档」的标注集，每周随文档更新做回归。

结果：端到端答案有用率（人工抽检，3 档评分）从 54% 提升到 81%；P95 延迟 3.2s；定位到的主要 badcase 是表格类 PDF 解析丢失结构，通过专用解析器修复。

点评：专业版的关键动作是自建评估集和混合检索的对比实验。这两个动作证明你不是跑通了 demo，而是真的在给「质量」负责。

案例三：数据分析 / 多步任务 Agent

平淡版：

开发了一个 AI 数据分析助手，用户可以自然语言提问，自动生成 SQL 并可视化结果，受到团队好评。

问题：「受到团队好评」是主观形容词；「生成 SQL」没有提怎么处理出错——而 text-to-SQL 的全部难点都在出错处理上。

专业版：

背景：业务团队日常取数依赖数据组排期，平均等待 2 天；目标是让运营能自助完成 80% 的常规取数。

任务：负责 SQL 生成 Agent 的可靠性设计：schema 上下文注入、生成结果的校验与自我修正、危险操作拦截。

行动：设计「生成 → 静态检查 → 试执行（只读 + LIMIT）→ 错误回灌自我修正」的循环，最多重试 3 次；为防 过度授权，数据库账号只读、白名单限定可访问表；用 120 条「问题-标准 SQL」做离线评估，按执行结果正确率计分。

结果：一次通过率 72%，含自我修正的最终通过率 91%；日均处理 200+ 查询，覆盖了业务方约 60% 的临时取数需求；单查询平均推理成本 ¥0.15，通过把简单查询路由到小模型降低了 40% 成本。

点评：这个案例展示的不仅是「能跑」，而是可靠性工程——校验循环、权限约束、成本路由。这是把 Agent 当产品做和当玩具做的区别。

数字必须是真的

上面所有数字都是占位示例。你自己的数字从三个地方来：自建评估集上实测、线上日志统计、A/B 对比。哪怕你的「线上」只有自己部署的 demo 和 20 个测试用户，也要写清楚统计口径。「在 50 条自测样例上准确率 84%」是诚实的；「准确率 99%」是自杀式的——面试官的第一个问题就会是「怎么测的」，然后一切结束。

三、技术栈关键词：正确的堆砌方式与红线

技术栈栏有双重读者：ATS/HR 的关键词匹配，和技术面试官的「真实性扫描」。前者要求你写全，后者要求你别乱写。两者并不矛盾，关键是分层 + 对齐 JD + 不越界。

正确的堆砌：分层写，和 JD 对齐

一份 2026 年合格的 Agent 工程师技术栈栏长这样（按你自己的真实情况删减）：

语言与基础    Python / TypeScript、FastAPI、异步编程、Docker
模型与 API    OpenAI / Anthropic / 豆包等主流模型 API、Function Calling、
              Structured Output、prompt caching
Agent 框架    LangGraph（状态图、checkpointer、human-in-the-loop）、
              OpenAI Agents SDK；了解 CrewAI / AutoGen 的取舍
检索与记忆    混合检索（BM25 + 向量）、rerank、pgvector / Qdrant、
              对话记忆与长期记忆设计
评估与观测    golden set 构建、LLM-as-judge、LangSmith / Langfuse trace 分析
工具生态      MCP（tool / resource / prompt）、REST API 封装

三个原则：

1. 先读 JD 再定关键词。不同公司对同一岗位的侧重差别很大（有的重 RAG，有的重多 Agent 编排，有的重私有化部署）。把 JD 里出现的技术词自然地落到你的技术栈和项目描述里——前提是你真的会。JD 的拆解方法见 JD 清单 和知识地图。
2. 分层意味着熟练度分层。写进「熟练」层的每一项都要经得起 15 分钟深挖；只是跑过 demo 的放到「了解」层。面试官对「熟悉 LangGraph」的标准追问是「checkpointer 存在哪、 interrupted 之后怎么恢复」，答不出就不要写「熟悉」。
3. 每个关键词最好能在项目里找到落点。技术栈栏写了「prompt caching」，项目里却没有任何成本优化描述，等于自曝是背的名词。

红线：写了就减分

• 编造或道听途说的名词。2026 年的招聘方已经会用「说出一个当前模型代际和定价」来筛查信息来源——只从二手文章获取信息的人会说出不存在的型号。写进简历的每个模型名、框架版本号，去官方文档核对一遍再写。
• 「精通」。这个行业里敢写精通的人要么是真大佬（不需要这份指南），要么是不知者无畏。写「熟练使用 X 完成过 Y 类项目」。
• 框架名罗列症。LangChain、LangGraph、LlamaIndex、Haystack、Semantic Kernel、AutoGen、CrewAI 全写上——正常工程师不可能全部深入用过。写 2-3 个你真正做过项目的，面试时能说清楚它们的取舍，反而加分。
• 与岗位无关的旧技术堆砌。投 Agent 岗，jQuery、SSH 框架就别占行了。篇幅是稀缺资源。
• 培训班式项目名。简历里出现和某培训课同款的「XX 智能客服/XX 知识库」项目名，面试官见得太多，直接降权。用你自己的场景命名。

四、没有相关工作/项目经验怎么办

这是转行和应届读者最关心的问题。Agent 方向有个独特的友好之处：这个领域存在还不到三年，「没做过商业项目」不是硬伤，「没有任何可验证的产出」才是。补齐路径有三条，按性价比排序。

路径一：作品集项目（性价比最高）

一个认真做的作品集项目可以完整替代一段工作经历——前提是它满足第二节里说的所有标准：有真实场景、有评估集、有数字、有故障复盘。具体做法：

1. 从作品集项目指南里选一个题目，或者更好：把你自己工作/生活中的一个真实痛点做成 Agent（用你熟悉的领域做场景，比复刻通用 demo 可信十倍）。
2. 按动手教程走完「搭建 → 评估 → 迭代」全流程，评估环节不许跳过——它是作品集和玩具的分界线。
3. 把项目部署成可访问的 demo，代码开源到 GitHub，README 写清架构图、评估方法和指标。
4. 简历上按 STAR 写，Situation 如实写「个人项目，解决 XX 场景问题」——不伪装成商业项目，面试官尊重诚实，且个人项目做到这个完成度本身就说明自驱力。

路径二：开源贡献（最能建立专业信誉）

给主流 Agent 框架提 PR 是一条被低估的路径。一份简历上写「LangChain/LangGraph contributor，N 个 PR 被合并」，对技术面试官的说服力约等于一段相关工作经历——它证明你能读懂大型代码库、遵守工程规范、和社区协作。

切入点（对新手按难度排序）：

1. 文档与示例：修正文档错误、补充示例代码、翻译。LangChain 这类大项目的 issue 区长期有大量文档类需求，维护者欢迎这类 PR，合并速度快，适合熟悉贡献流程。
2. 边界 case 修复：从 issue 列表里找带 good first issue 标签的 bug，通常是异常处理、类型标注、边角行为不一致这类问题。修这类 bug 的过程就是读框架源码的过程。
3. 测试补充：给缺少测试的模块补测试用例。技术含量不低，竞争小，且逼你理解模块的契约。
4. 小而完整的功能：做到前三步之后，你自然会发现框架里缺什么。

LangGraph、CrewAI、AutoGen、OpenHands 都是活跃且对贡献者友好的目标。策略上建议深耕一个框架（3-5 个合并的 PR）而不是每个项目刷一个 typo 修复——前者叫 contributor，后者叫刷记录，面试官分得出来。

路径三：公开写作（放大器）

把你做项目、修 bug 的过程写成技术复盘：架构决策记录、评估方法、踩坑分析。发在个人博客或技术社区。它的作用不是「证明你会写」，而是给简历上的每个声明提供可验证的证据链——面试官真的会点进链接看。写 AGENTS.md、给项目写文档也是同类练习，见写好 AGENTS.md。

三条路径的组合拳

理想组合是：1 个有完整评估的作品集项目 + 同一技术栈上 2-3 个开源 PR + 2-3 篇复盘文章。三者互相印证，构成「这个人在认真进入这个领域」的完整证据链。准备周期通常 2-4 个月，比海投 200 份平庸简历有效得多。

五、常见减分项清单

下面这些是招聘侧讨论中反复被点名的简历减分项，按严重程度排序。每一条都附上「面试官看到时的内心活动」，方便你自查。

1. 声称 100% 或接近满分的准确率。看到即判定「不懂 eval」。真实系统永远有失败率，写 91% 并说明失败样例是什么的人，比写 99% 的人可信一百倍。
2. 「实现了 RAG」但没有任何召回/质量数字。招聘方的默认解读：只跑通过 demo。任何认真做过的检索系统都会留下 recall@k 或命中率指标。
3. 全程无成本意识。项目描述里从头到尾没提过 token 成本、延迟、模型选型——说明没有在预算约束下做过东西。成本工程是这个岗位的日常，不是锦上添花。
4. 项目描述一片光明，零失败记录。像教程复刻。真实项目必然有坑，不写坑 = 没踩过坑 = 没做到足够深的程度。
5. 「训练/微调了大模型」的误用。把调 API 写成「训练模型」，把 LoRA 微调 7B 模型写成「自研大模型」。这是诚信问题，不只是措辞问题——术语误用会让面试官怀疑整份简历。
6. 关键词与项目脱节。技术栈栏琳琅满目，项目描述里一个都用不上。
7. demo 无证据。说「开发了 XX 系统」但没有 GitHub 链接、没有可访问的 demo、没有任何第三方可以验证的东西。2026 年了，Agent 项目的交付物天然适合公开验证，不给链接等于放弃加分。
8. 一稿多投，不读 JD。同一份简历投所有公司。JD 里明确写了「多 Agent 编排经验优先」，你的相关项目却埋在第三段——这是把过初筛的机会拱手让人。
9. 夸大团队项目中的个人贡献。「负责」和「参与」混用，面试追问「哪部分是你做的」时露馅。写清楚你独立完成的边界，反而显得成熟。
10. 简历里出现过时信息而不自知。比如把已被官方废弃的 API 写法、上一代的模型名当作亮点写出来。这个领域按季度变化，简历上的每个技术声明都要能用「我最近还在用」来捍卫。

六、投递前自评表：20 项检查

投递前对照过一遍。任何一项答「否」，先改简历再投。

项目与成果

• [ ] 1. 每个项目都能用一句话说清「解决了谁、什么问题」
• [ ] 2. 每个项目至少有一个可量化的结果指标
• [ ] 3. 每个数字我都能回答「怎么测的、样本量多少、口径是什么」
• [ ] 4. 至少一个项目写了评估方法（测试集、指标定义、评分方式）
• [ ] 5. 至少一个项目写了成本或延迟数据
• [ ] 6. 至少一个项目写了真实踩过的坑和修复过程
• [ ] 7. 每个项目都写清了我个人的贡献边界（「负责」「参与」不混用）

技术与关键词

• [ ] 8. 通读过目标 JD，JD 里的关键技术词在我简历中（真实地）出现了
• [ ] 9. 技术栈分了熟练度层次，没有通栏「精通」
• [ ] 10. 技术栈里每一项都能在项目描述中找到对应落点
• [ ] 11. 每个模型名、框架名、版本号都在官方文档核对过
• [ ] 12. 没有罗列自己没深入用过的框架
• [ ] 13. 删掉了一两句「熟练使用 Office」式的占位废话

证据链

• [ ] 14. 至少一个项目附了 GitHub 链接，repo 有可读的 README 和架构说明
• [ ] 15. 有 demo 的项目附了可访问的链接（或截图/录屏）
• [ ] 16. 开源贡献写了具体 PR 数量或链接，能经得起点进去看
• [ ] 17. 有技术文章的话，链接有效且内容与简历声明一致

诚信与细节

• [ ] 18. 没有把「调 API / 微调」写成「训练/自研模型」
• [ ] 19. 没有 100%、99% 这类无法捍卫的数字
• [ ] 20. 通读全文，没有一个形容词是「负责了、提升了、优化了」之后不接具体对象的

最后一道人工测试

把简历给你身边最懂技术的工程师朋友看 5 分钟，只问一个问题：「看完你觉得我做过什么？」如果他的回答和你实际做过的事对不上，说明简历没有传达出有效信息——继续改，改到对得上为止。

简历通过只是第一关。简历上写的每一项都会在面试里被展开追问，提前用面试题库演练一遍，确保纸面上的每个声明都能口头兑现。

参考资料

• AI Developer Hiring 2026: Skills That Actually Matter —— 2026 年招聘侧视角：eval 素养、成本意识为何是筛简历的核心信号，以及 12 条简历红线
• 2025年AI从业者薪资揭秘：大模型应用开发工程师职业路径与技能要求 —— 国内大模型应用岗的能力维度拆解（工程基础、RAG 优化、业务落地）
• 开源 Agent 项目推荐 + 如何用它们丰富简历 —— 给 LangChain/LangGraph 等框架提 PR 的具体切入策略
• 大模型方向简历怎么写？项目经历写"调用了GPT API"，面试官直接挂 —— 国内面试官视角对功能清单式写法的批评与改进方向
• 2026大厂AI技术简历写作指南 —— JD 关键词提取与简历对齐的实操方法
• AI 岗位全景与转行指南：从技能到 Offer —— AI 应用工程师方向的转行路径与 STAR 量化写法
• AI Engineer Resume Guide (2026) —— 英文视角的 AI 工程师简历结构建议：技术栈前置、项目先于工作经历