这篇不是教程，是我这几年做 Agent 项目反复踩坑后的一张「能力地图」。如果你正在准备相关岗位，或者已经在做、但总觉得交付得心虚，可以对着往下看。文末列了自查清单。
这几年我一直在 AI Agent 应用开发一线。项目做多了才慢慢琢磨明白：这行真不是调个接口、写段提示词就能交差的。
岗位实际要的是——能独立撑起一套系统：任务规划、工具编排、状态管理、异常兜底，最好还能部署上线。
我翻过不少招聘 JD，发现写得最狠的一条其实是这句：「至少完整参与过一个已上线或实际使用的 Agent 项目，并能说明个人职责、技术架构、工具调用、问题优化及上线效果。」
这句话筛掉的，恰恰是那些"Demo 都能跑、线上都出事"的人。下面按六个层次拆。
1基础不过关，后面全是空中楼阁
很多人上来就学 LangGraph，结果卡在异步和状态管理上——不是框架难，是地基没打好。
Python 这块，别只停在写脚本。重点是异步、装饰器、数据结构、异常处理，加上 FastAPI。异步不是为了炫技，是因为 Agent 天生就是并发调工具、并发等模型返回的活儿。装饰器是工具函数和中间件封装的地基——你做权限校验、重试、日志埋点，早晚绕不开它。
大模型这块，得懂机制而不是背名词。Token 怎么算的、上下文窗口怎么爆的、Prompt 怎么写才稳定、Function Calling 的完整链路、结构化输出怎么强约束、幻觉怎么控。这几个东西你不知道原理，出了问题只能靠猜。
后端这块是分水岭。Redis、MySQL、Docker、API 设计，外加并发、日志、任务调度。它决定你写的是"能演示的程序"还是"能运行的服务"。差别就在这。
有一句话我想单独强调：每学一块都写个 Demo，能跑通才算真会。看十篇文章，不如自己把异步工具并发调一次。
2核心五件套，决定你能做多复杂
这一层是真正拉开差距的地方。同样用 LangGraph，有人能做出客服系统，有人只能做出一个会聊天的壳子。
架构。ReAct 和 Plan-and-Execute 是两套底层思路：一个边想边做，一个先想完再做。你要能把任务拆解、规划、执行、反思、校验串成一条完整的线，而不是只在某一步用上大模型。
工具。Function Calling 只是入口。Schema 怎么定义得让模型不选错、参数怎么校验、多个工具怎么路由分发、超时怎么重试、失败了怎么兜底——这些才是工具层真正的工程量。工具描述写得含糊，模型就会乱选，再怎么调 Prompt 都救不回来。
工作流。LangGraph 的 State、Node、Edge、Checkpointer 必须熟。State 是共享状态，Node 是执行单元，Edge 决定下一步去哪，Checkpointer 负责存盘。更要紧的是分清 Workflow 和 Agent 各自的适用场景：步骤固定、能画出来的，用 Workflow，可测、可控、成本低；下一步要看工具返回什么再决定的，才交给 Agent 自己做判断。
记忆。短期记忆、长期记忆、上下文压缩、历史检索。多轮对话丢信息是最常见也最伤体验的 bug，而它往往不是模型的问题，是你没设计好哪些该留、哪些该压、哪些该去检索。
多 Agent。Supervisor、Planner、Executor 的分工协作。任务怎么分发、结果怎么汇总、某个子 Agent 挂了怎么办，这三件事都得管住。多 Agent 不是把活拆给更多 Agent 就更强，拆不好只会多出好几个出错点。
3项目得有强度，Demo 不算
面试聊项目时，最容易被追问的不是"你用了什么技术"，而是"这里出问题了你怎么办"。所以项目强度不看你做了几个，看你能不能兜住麻烦。
至少独立做三个，且场景要有区分度：
一、客服 Agent——多轮对话、知识库、订单查询、工具调用、人工转接。它练的是意图识别和转人工的边界判断。
二、办公 Agent——能理解任务、拆步骤、调工具、查结果、状态持久化。它练的是长流程里"做到一半断了还能接上"。
三、多 Agent 系统——Planner 规划、子 Agent 执行、Supervisor 调度汇总。它练的是分工与协同。
别只满足于跑通。失败恢复、工具异常、无限循环，这三样都要兜住。尤其无限循环——不设最大轮次和收敛判断，一次线上调用就能烧掉你半个月的预算。
4工程能力，是能不能交付的那道门
这一层不写代码也能讲一堆，但一上线就露馅。
部署。FastAPI 起服务、Docker 打镜像、Redis 做缓存和会话、SSE 做流式输出。Agent 响应慢是常态，流式输出不是锦上添花，是用户体验的必需品。
稳定性。超时、重试、幂等、断点恢复、权限隔离、人工确认。特别说一句幂等：模型调用重试一般安全，但支付、发邮件、建工单、改数据库这些有副作用的操作，重试一次就是事故。要么用幂等键，要么加人工确认。
可观测。Trace、日志、调用链。线上出问题时，你要能快速定位到底是模型输出错、工具调用失败，还是任务中途被打断了。这三类问题的排查路径完全不同，混在一起做监控，等于没有监控。
5会评估，才会优化
很多人做 Agent 是"感觉变好了"就上线。但感觉不能当指标用。
建一个小而准的测试集，盯五个数：任务完成率、工具调用准确率、执行成功率、延迟、Token 成本。前三个说对不对，后两个说值不值。
然后定期收 Bad Case。关键是分类，而不是看到一条改一条：是模型决策错了（推理不到位）、工具选错了（描述或 Schema 有问题）、还是上下文不够（检索或记忆没接上）？三种病因，三种药。分不清就在乱改 Prompt，改十版也白改。
6工具与资源，怎么用才不浪费
框架上，LangGraph、LangChain、OpenAI Agents SDK 挑一个吃透就够了。协议层面，MCP 和 Function Calling 现在基本是标配。调试评估，LangSmith、Langfuse 这类工具越早接越好，别等出问题才想起没埋点。
资源方面，吴恩达的 Agent 课程、LangGraph 官方文档、Datawhale 的教程都是不错的路子。但最后这条最值钱：GitHub 项目别只看 README。README 写的是它想让你看到的样子。重点翻三处：架构怎么分层的、工具怎么封装的、异常怎么处理的。这三处看完，才等于读了一个项目。
说回开头那句 JD。
这行拼的不是你会多少个框架。框架三个月换一茬，LangChain 的 API 我自己都被坑过几回。
真正被考的，是让 Agent 把活干完、干对，出错还能恢复。做到这三件事，才叫具备岗位能力。
前两条靠架构和提示词，第三条只靠工程。而工程，恰恰是最多人空着的那块。
附：自查清单
□ 有没有一个项目，我能讲清它的架构分层和一次真实故障
□ 我的工具描述，换个人看能不能一次选对
□ 状态存盘了吗？断在半路能不能接着跑
□ 有没有最大轮次和收敛判断，防止无限循环
□ 有副作用的操作，加没加幂等或人工确认
□ 线上能不能一眼看出是模型错、工具错还是流程断
□ 我的完成率和 Token 成本，能不能报出具体数字
第七条没做到，前面的积累就很难被承认。
你在第几条上卡住过？评论区聊聊。