• OneX AI：AI 学习社区，16+ 高质量体系课、4+ 实战项目，涵盖 Go、云原生、AI 。
• GZH 令飞编程：分享 Go、云原生、AI Infra 相关技术。回复「资料」免费下载 Go、云原生、AI 等学习资料

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 类）
成本优化 / 容量规划	编译器与算子（部分归芯片厂）
边缘/端侧推理	—

三个容易误判的地方

1. JD 标题会低估推理岗：很多推理工作挂在「后端开发」「云原生平台」「SRE」「AI 平台工程师」下面，搜「推理」搜不到。
2. 训练岗被高估：模型厂岗位曝光度高，但 headcount 很小；一个大模型团队可能只有十几个训练 Infra，而支撑全公司业务的推理平台有上百人。
3. RL 后训练在变热：verl 这类「训练 + 推理混合」岗位在增加，属于两者交界，既懂推理引擎又懂训练框架的人最抢手。

对你的建议

• 如果目标是「岗位多、好转、能积累工程纵深」：主攻推理平台与推理调度（第 5、6 类），这是 Go/K8s 背景最顺的路。
• 如果目标是「技术壁垒高、岗位少但单价高」：训练框架/并行（第 4 类），但要接受门槛（Python/C++、读源码、集群经验）。
• 最稳的组合：推理引擎懂到能压测调参 + 推理调度做到能落地，同时了解训练调度（第 3 类）——因为算力平台/调度岗同时服务训练和推理，这部分技能是复用的。