AI Agent开发/架构师
岗位解读
定位：把模型能力封装成产品与业务系统。这是目前增长最快、也最"软件工程"的一类。
典型职责
- Agent 框架与运行时：任务规划、工具调用（Function Calling / MCP）、多轮执行、错误恢复
- 记忆与上下文（Context Engineering）：长期记忆、会话压缩、检索增强（RAG）、召回排序
- 业务侧 AI 应用：客服、创作、营销、支付、办公协同等场景的 AI 功能后端
- 平台化：把上述能力沉淀为可复用 SDK / 工作流 / 编排引擎
- 效果与成本：延迟、Token 成本、成功率、线上稳定性
硬门槛
- 一门后端语言（Go / Python / TypeScript / Java 均常见；JD 中 Go 与 Python 各约 45%）
- 扎实的分布式系统与工程能力：高并发、缓存、消息队列、可观测
- 理解 LLM 的能力边界：Prompt、上下文窗口、幻觉、结构化输出
加分项
- 深度使用过 LangGraph / AutoGen / MCP / OpenAI Agents SDK 等框架，并能判断其边界
- 做过 RAG 全链路（切分、Embedding、召回、重排、评测）
- 有 Agent 的评测与数据闭环经验（从线上失败样本到改进）
- 熟悉 AI Coding 工具（352 个岗位明确要求"会用 AI 编程工具并判断其能力边界"）
AI Agent 开发/架构师学习路线
| 类别 | 内容 | 开源项目 |
|---|---|---|
| Agent 原理与运行机理 | Agent 基元 LLM 交互工程 多智能体协作 | Eino MCP Go SDK LiteLLM |
| RAG 与长期记忆 | RAG 全链路 记忆（Context Engineering） 缓存与一致性 | Eino RAGFLow Milvus Mem0 pgvector |
| 工具调用协议、沙箱与权限 | 工具级授权 沙箱执行（HITL/审批） 审计日志 | OPA RBAC |
| Agent 评测与数据闭环 | 评测体系 离线任务集（50 条起步，覆盖成功/失败/边界） LLM-as-Judge（但要会规避 judge 自嗨：用证据约束、rubric） 指标：成功率、平均步数、P95 延迟、Token 成本、拒答/安全命中率 线上数据闭环 失败归因标签体系（工具异常/检索不准/输出不合法/超时/安全拒绝） 采样策略：以"失败为主 + 部分成功对照" 回放与回归：固定模型版本/提示版本做对比 | Eino Ragas |
| 平台化（SDK / 工作流 / 编排引擎） | SDK 化：工具注册、提示模板、参数校验、事件回调 工作流编排：支持多步任务、并行、取消、回滚 产品化能力： | Eino Temporal |
AI Infra 岗位
方向：
| 细分 | 核心问题 | Go 的角色 | 关键知识 |
|---|---|---|---|
| 推理调度 | 请求怎么分到 GPU、如何提高利用率 | 调度器、网关、队列、限流 | KV Cache、PD 分离、批处理、SLO |
| 训练平台/存储 | 千卡训练怎么不中断、Checkpoint 怎么快 | Operator、存储编排、容错 | CSI、Fluid/Alluxio、RDMA |
| 集群运维 | 万卡集群怎么稳 | 控制器、自愈、观测 | GPU 故障模式、健康检查、拓扑 |
岗位解读
定位：让大模型在真实集群上跑得快、跑得稳、跑得便宜。
典型职责
- 推理：推理引擎适配、KV Cache 优化、PD 分离、Continuous Batching、投机解码、量化
- 训练：分布式并行（数据/张量/流水线/专家并行）、显存管理、通信优化、训练稳定性与容错
- 调度：异构算力池化、潮汐资源、Quota 管理、推理流量调度与弹性
- 存储/网络：训练数据读取、Checkpoint 存储（PV/CSI）、RDMA、集群网络
- 观测与 SRE：GPU 集群稳定性、故障自愈
硬门槛
- C++/Go/Python 至少一门（JD 中 C++ 75%、Python 60%、Go 23%）
- 分布式系统原理 + Linux + 容器/编排
- 理解 GPU 架构与瓶颈（不一定要写 CUDA，但要会定位瓶颈）
加分项
- 熟悉 vLLM / SGLang / TensorRT-LLM；Megatron / DeepSpeed / verl
- K8s 深度经验（PV/CSI、Device Plugin、调度器扩展）------Go 岗位的主战场
- 大规模集群的真实经验（数千卡以上）
- 顶会论文（OSDI/SOSP/FAST/NSDI 在存储与系统岗位被明确点名）
AI Infra（训/推 + 调度 + 存储网络 + 运维）学习路线图
- 在大厂模型团队里两者接近，但在绝大多数「用模型」的公司里，推理岗是训练岗的数倍。（因为很多公司不会自己训练模型）
| 类别 | 核心知识点 | 开源项目 |
|---|---|---|
| 通用底座 | namespace/cgroup、容器运行时、K8s 对象模型与调度流程、CRD/Operator、GPU 架构（SM/显存/带宽/PCIe/NVLink）、nvidia-smi/DCGM | Kubernetes、containerd、NVIDIA Container Toolkit |
| GPU 资源管理与池化 | NVIDIA Device Plugin 机制：设备发现→注册→分配→注入到容器（资源隔离/挂载） NVIDIA GPU Operator：驱动/运行时/插件的自动化运维 MIG / 多实例 GPU：算力切分、资源隔离粒度与调度影响 K8s 拓扑感知/节点标签（为后续"把任务调到 NVLink 更近的 GPU"做铺垫） | NVIDIA/k8s-device-plugin **NVIDIA/gpu-operator ** kubernetes-sigs/node-feature-discovery (NFD) HAMi |
| 训练任务调度 | 作业模型：TrainingJob / PodSet / worker 数、并行度参数如何映射到资源请求 队列与配额：tenant 隔离、优先级、资源额度（Quota）与配额（quota admission） Gang scheduling / 成组调度：保证并行度一起就位（避免只启动一半导致浪费/失败） 弹性与抢占： 调度约束： 作业到 Pod 的编排：controller 如何创建/回收 worker；失败如何归因与回放 | Volcano Kueue koordinator |
| 训练平台与分布式并行 | ZeRO / TP / PP / EP 的适用边界 显存管理：分片、Offload、激活检查点 通信优化与计算重叠 容错 checkpoint 与恢复流程 | DeepSpeed |
| 推理加速（推理引擎优化） | PagedAttention / KV Cache paging：为什么能降低碎片与显存浪费 Prefix/Decode 两阶段：预填充与生成分离的收益 PD 分离（Prefix-Decode separation）： Continuous Batching 与 批处理策略：合并请求、避免长尾拖垮整体延迟 SLO 驱动的工程：如何设置超时/回退/降级（比如减少并发或启用更小上下文策略） | vLLM |
| 推理调度与在线系统 | 网关：鉴权、路由、超时、重试、限流 模型感知路由与 KV-aware 调度 副本管理与灰度 弹性容量规划（队列/利用率驱动） SLO 与降级策略 | ★ Gateway API Inference Extension 2. KServe 3. llm-d |
| 训练数据 / 存储编排 | CSI/PV：卷如何被挂载、扩容、回收策略 分布式存储/对象存储/本地缓存策略 数据预热与冷热数据分层 Checkpoint 写入带宽 | ★ Fluid 2. JuiceFS 3. Alluxio |
| 高速网络 | Multus 多网卡与副 CNI SR-IOV 设备直通 RDMA / RoCE 与 GPUDirect 网卡拓扑如何进入调度 | ★ Multus< 2. SR-IOV Device Plugin 3. RDMA Shared Device Plugin |
| 观测、运维与自愈 | GPU 健康检查：温度/错误码/重试次数/PCIe 链路异常 观测体系：利用率、显存碎片、KV cache 指标、训练吞吐、排队延迟分布 自愈策略：驱逐/重调度、Pod 级回滚、作业级弹性恢复 故障隔离：tenant/队列隔离、防止雪崩 | Prometheus、Grafana、DCGM Exporter、kube-state-metrics、node-problem-detector、Chaos Mesh |
| 平台化与成本 | 混部与 QoS、资源超卖、弹性伸缩、成本分摊、容量规划、多租户 API | Koordinator、Karpenter、OpenCost、Kueue |
推理与训练岗位对比
| 推理侧（量大、层次多） | 训练侧（量少、门槛高） |
|---|---|
| 推理平台/模型服务 | 训练框架（DeepSpeed） |
| 推理引擎/加速 vLLM | 分布式训练与通信 |
| 推理调度/网关 | 训练平台与作业调度 |
| GPU 调度与算力平台 | 集群与存储/网络 |
| AI SRE / GPU 运维 | RL 后训练 Infra（verl 类） |
| 成本优化 / 容量规划 | 编译器与算子（部分归芯片厂） |
| 边缘/端侧推理 | --- |
三个容易误判的地方
- JD 标题会低估推理岗：很多推理工作挂在「后端开发」「云原生平台」「SRE」「AI 平台工程师」下面，搜「推理」搜不到。
- 训练岗被高估：模型厂岗位曝光度高，但 headcount 很小；一个大模型团队可能只有十几个训练 Infra，而支撑全公司业务的推理平台有上百人。
- RL 后训练在变热：verl 这类「训练 + 推理混合」岗位在增加，属于两者交界，既懂推理引擎又懂训练框架的人最抢手。
对你的建议
- 如果目标是「岗位多、好转、能积累工程纵深」：主攻推理平台与推理调度（第 5、6 类），这是 Go/K8s 背景最顺的路。
- 如果目标是「技术壁垒高、岗位少但单价高」：训练框架/并行（第 4 类），但要接受门槛（Python/C++、读源码、集群经验）。
- 最稳的组合：推理引擎懂到能压测调参 + 推理调度做到能落地，同时了解训练调度（第 3 类）------因为算力平台/调度岗同时服务训练和推理，这部分技能是复用的。