2026 AI 应用工程师求职技术栈:东京、中国大陆与美国市场 JD 深度调研
面向希望在日本东京、中国大陆,或美国公司日本分部寻找 AI Application Engineer、AI Agent Engineer、RAG Engineer、Applied AI Engineer、LLM Application Engineer 等岗位的工程师。
摘要
2026 年的 AI 应用岗位已经明显越过“会调用大模型 API、会写 Prompt 就能入行”的阶段。
在近期公开招聘信息中,企业真正反复要求的是一套完整的工程能力:
Python 后端工程 + RAG/搜索 + Agent 编排 + 云部署 + 评测与可观测性 + 安全和可靠性。
本次调研以中国大陆、美国和东京三个市场各 20 条、合计 60 条近期公开 JD 为人工编码样本,覆盖以下岗位名称:
- AI Application Engineer
- AI Agent / Agentic AI Engineer
- RAG Engineer
- Generative AI Engineer
- Applied AI Engineer
- AI Backend Engineer
- AI/LLM Engineer
- Forward Deployed / AI Solutions Engineer
三个市场合并后,样本中出现频率最高的技术方向依次是:
- Python
- Agent、Tool Calling 与工作流编排
- RAG
- 后端、API 与微服务
- LangChain
- 向量检索、Embedding 与搜索
- Evaluation、Observability 与 LLMOps
- LangGraph
- AWS、Azure、GCP 等云平台
- Prompt / Context Engineering
但是,招聘出现频率不等于学习顺序。对于希望在东京求职的工程师,最优先的技术路线应当是:
Python/FastAPI → 生产级 RAG → LangChain v1/LangGraph v1 → AWS → PostgreSQL/OpenSearch → Evaluation/Observability → Docker/Terraform/CI/CD → Agent 安全与 Human-in-the-loop。
一、研究范围与方法
1.1 样本范围
本次样本按市场分为三组:
| 市场 | 样本数 | 主要来源 |
|---|---|---|
| 中国大陆 | 20 | 智联招聘、猎聘等 |
| 美国 | 20 | LinkedIn、Wellfound、Ashby、Greenhouse、SmartRecruiters 等 |
| 东京及可在东京任职的日本岗位 | 20 | Findy、Green、Wantedly、LinkedIn、Tokyo Job 等 |
| 合计 | 60 | 近期公开 JD |
调研日期为 2026 年 7 月 28 日。招聘页面可能在读者查看时已经关闭、重新发布或修改,因此本文反映的是调研时点的市场快照,而不是永久不变的数据。
1.2 岗位纳入标准
纳入:
- 以 LLM 应用、AI Agent、RAG、生成式 AI 产品为核心职责;
- 要求工程实现、系统集成、部署或生产运维;
- 工作内容与 AI Application、Agent、RAG、Applied AI、AI Backend 高度相关。
排除:
- 纯计算机视觉岗位;
- 纯传统机器学习、推荐算法或数据分析岗位;
- 纯基础模型预训练研究岗位;
- 纯销售、售前或无实际开发职责的岗位;
- 只把“使用 ChatGPT/Copilot”作为办公工具、但不开发 AI 产品的岗位。
1.3 计数规则
每条 JD 对同一个技术类别最多计数一次。只有职位描述、技术栈、必需条件或加分条件中 明确出现 的能力才计入。
例如:
FastAPI、REST API、微服务统一归入“后端/API/微服务”;Pinecone、Milvus、Qdrant、FAISS、OpenSearch、pgvector统一归入“向量检索/Embedding/搜索”;LangSmith、Langfuse、OpenTelemetry、evaluation harness、tracing统一归入“评测/可观测性/LLMOps”;tool use、function calling、multi-agent、orchestration统一归入“Agent/工具调用/编排”。
1.4 如何正确理解百分比
每个市场样本量为 20,因此一条 JD 对应 5 个百分点。两个技术相差 5%~10% 时,不应过度解读为绝对高低,更适合看作同一梯队。
这些数字是:
近期公开 JD 的样本出现率。
它们不是:
- 整个国家所有岗位的全量市场占有率;
- 技能必须程度的精确比例;
- 未来几年的固定预测;
- 招聘平台官方统计。
此外,本研究本身聚焦 Agent、RAG 和 AI Application 岗位,因此这些方向的出现率天然高于整个广义 AI 就业市场。
二、三个市场合并后的技术频率
2.1 60 条 JD 综合排名
| 排名 | 技术方向 | 出现职位数 | 样本出现率 |
|---|---|---|---|
| 1 | Python | 57/60 | 95% |
| 2 | Agent、Tool Calling、工作流编排 | 53/60 | 88% |
| 3 | RAG / 检索增强生成 | 50/60 | 83% |
| 4 | 后端、API、微服务 | 41/60 | 68% |
| 5 | LangChain | 37/60 | 62% |
| 5 | 向量数据库、Embedding、搜索 | 37/60 | 62% |
| 7 | 评测、可观测性、LLMOps | 36/60 | 60% |
| 8 | LangGraph | 31/60 | 52% |
| 9 | AWS、Azure、GCP 等云平台 | 30/60 | 50% |
| 10 | Prompt / Context Engineering | 28/60 | 47% |
| 11 | Docker / Kubernetes | 23/60 | 38% |
| 12 | SQL、关系数据库、数据工程 | 20/60 | 33% |
| 13 | Guardrails、安全、HITL、审计 | 16/60 | 27% |
| 14 | 微调、模型部署、推理优化 | 15/60 | 25% |
| 15 | PyTorch、TensorFlow、Hugging Face | 12/60 | 20% |
| 16 | TypeScript / JavaScript | 11/60 | 18% |
| 17 | CI/CD、Terraform 等 IaC | 10/60 | 17% |
| 18 | Java | 9/60 | 15% |
| 18 | MCP | 9/60 | 15% |
| 18 | 知识图谱 / GraphRAG | 9/60 | 15% |
| 21 | Go | 6/60 | 10% |
2.2 这组数据真正说明了什么
AI Application Engineer 本质上首先是软件工程师
Python、后端/API、数据库、云、Docker 和 CI/CD 的高频出现说明,企业需要的不是只会做 Notebook 实验的人,而是能够:
- 把模型能力封装为稳定 API;
- 与数据库、企业系统和第三方 SaaS 集成;
- 处理并发、超时、重试和错误;
- 部署到云端;
- 监控成本、延迟和质量;
- 对线上结果负责。
Agent 已经从“演示概念”变成工程岗位关键词
大量 JD 不再满足于简单 Chatbot,而是明确要求:
- Tool Calling / Function Calling;
- Planning;
- Memory 与 State;
- 多步骤工作流;
- Multi-Agent;
- Retry / Repair Loop;
- Human-in-the-loop;
- 与企业 API、数据库、CRM、邮件和工单系统交互。
RAG 仍然是最稳定、最普遍的企业落地场景
企业数据通常无法直接交给通用模型,也不适合依靠模型参数记忆。因此,RAG 仍是 AI 应用岗位最稳定的技能入口。
真正的企业 RAG 不只是“向量数据库 + LLM”,而是:
数据接入
→ 文档解析与清洗
→ Chunking
→ Metadata 与权限
→ Embedding
→ Dense/BM25/Hybrid Retrieval
→ Rerank
→ Context 构造
→ 带引用回答
→ 离线与在线评测
→ 监控与持续优化
Evaluation 和 Observability 已经成为生产岗位分水岭
在美国样本中,这一类能力尤其突出。企业越来越明确地要求:
- Golden Dataset;
- Regression Suite;
- Task Success Rate;
- Retrieval Evaluation;
- Tracing;
- Failure Taxonomy;
- Cost / Latency Metrics;
- Prompt 和模型版本管理;
- Release Gate;
- A/B Test;
- Guardrail Threshold。
能做出 Demo 的人很多,能证明系统“为什么可靠、如何持续变好”的人仍然稀缺。
三、中国大陆市场:应用落地、私有化与国产模型生态
3.1 中国大陆 20 条 JD 技术频率
| 排名 | 技术方向 | 出现职位数 | 出现率 |
|---|---|---|---|
| 1 | Agent、工具调用、工作流编排 | 19/20 | 95% |
| 2 | Python | 18/20 | 90% |
| 2 | RAG | 18/20 | 90% |
| 4 | 后端、API、微服务 | 15/20 | 75% |
| 5 | LangChain | 14/20 | 70% |
| 5 | 向量数据库、Embedding、搜索 | 14/20 | 70% |
| 7 | Prompt / Context Engineering | 12/20 | 60% |
| 7 | 评测、监控、LLMOps | 12/20 | 60% |
| 9 | Docker / Kubernetes | 9/20 | 45% |
| 10 | LangGraph | 8/20 | 40% |
| 10 | 微调、模型部署、推理优化 | 8/20 | 40% |
| 12 | Java | 7/20 | 35% |
| 12 | SQL、关系数据库、数据工程 | 7/20 | 35% |
| 14 | MCP | 4/20 | 20% |
| 14 | PyTorch / TensorFlow / Hugging Face | 4/20 | 20% |
| 14 | 知识图谱 / GraphRAG | 4/20 | 20% |
近期中国 JD 已经频繁把 FastAPI、LangChain/LangGraph、RAG、向量数据库、PostgreSQL、Docker、MCP、Function Calling 和评测放在同一岗位中。武汉菱电的智能体工程师职位就是典型组合:Python、FastAPI、LangChain、LangGraph、Weaviate/Pinecone/Milvus、PostgreSQL、Docker、CI/CD、MCP 和 OpenTelemetry 同时出现。1
3.2 中国市场的三个突出特点
特点一:国产模型、私有化和推理部署更常见
中国岗位更容易明确出现:
- Qwen / 通义千问;
- DeepSeek;
- GLM / 智谱;
- Dify、Coze、n8n;
- vLLM、SGLang、LMDeploy;
- LoRA / QLoRA;
- 本地模型服务;
- GPU 服务器管理;
- 私有知识库。
这解释了为什么“微调、模型部署与推理优化”在中国样本中达到 40%,明显高于东京 AI Application 样本。
中科软的 JD 同时要求 Java/Python、LangChain、Spring AI、LangGraph、MCP、Milvus、Neo4j、Rerank、Qwen、GLM、DeepSeek、LoRA/QLoRA 与 vLLM,体现了中国大型企业系统中“AI 应用 + 国产模型 + 原有 Java 业务系统”的典型组合。2
特点二:Java 仍然有现实价值
在中国的传统企业、金融、保险、制造、政企和 SI 项目中,AI 模块经常需要接入:
- Spring Boot;
- Spring Cloud;
- Spring AI;
- MyBatis;
- MySQL / OceanBase;
- Redis / RabbitMQ;
- 既有微服务体系。
因此,Python 是 AI 应用主语言,但 Java 并没有失去价值。对于已有 Java 后端经验的人,最合理的策略不是放弃 Java,而是形成:
Python 负责 AI/RAG/Agent 服务,Java 负责既有核心业务系统与企业集成。
特点三:低代码 Agent 平台是交付工具,不是核心竞争力
Dify、Coze、n8n、RAGFlow 在中国 JD 中经常出现。它们适合:
- 快速 PoC;
- 业务流程试验;
- 非核心工作流;
- 客户演示;
- 内部自动化。
但招聘中真正能形成高价值差异的仍然是:
- 能否用代码实现可维护的 Agent;
- 能否做检索与评测;
- 能否处理状态、重试、权限和异常;
- 能否与企业 API 和数据库集成;
- 能否部署和运维。
只会在平台上拖拽节点,难以替代生产级 AI Application Engineer。
四、美国市场:评测、可靠性、安全和系统设计门槛最高
4.1 美国 20 条 JD 技术频率
| 排名 | 技术方向 | 出现职位数 | 出现率 |
|---|---|---|---|
| 1 | Python | 20/20 | 100% |
| 2 | RAG | 19/20 | 95% |
| 3 | Agent、工具调用、工作流编排 | 18/20 | 90% |
| 4 | 评测、可观测性、LLMOps | 14/20 | 70% |
| 5 | LangChain | 13/20 | 65% |
| 5 | LangGraph | 13/20 | 65% |
| 7 | 后端、API、微服务 | 12/20 | 60% |
| 7 | 向量数据库、Embedding、搜索 | 12/20 | 60% |
| 9 | 云平台 | 11/20 | 55% |
| 10 | Prompt / Context Engineering | 10/20 | 50% |
| 10 | Guardrails、HITL、安全、审计 | 10/20 | 50% |
| 12 | Docker / Kubernetes | 9/20 | 45% |
| 13 | CI/CD、Terraform 等 IaC | 5/20 | 25% |
| 13 | SQL、关系数据库、数据工程 | 5/20 | 25% |
| 13 | 微调、模型部署、推理优化 | 5/20 | 25% |
| 16 | PyTorch / TensorFlow / Hugging Face | 3/20 | 15% |
| 16 | TypeScript / JavaScript | 3/20 | 15% |
| 18 | MCP | 2/20 | 10% |
EXL 的 Agentic AI Engineer 职位非常具有代表性:除了 Python、LangChain、LangGraph、RAG、向量数据库、FastAPI、微服务和云,还明确要求 evaluation harness、tracing、metrics、rollback、guardrails、auditability、HITL、CI/CD 和 PII/PHI 安全。3
4.2 美国市场的四个突出特点
特点一:框架只是手段,生产系统能力才是硬门槛
美国岗位经常使用这样的措辞:
- shipped to production;
- production ownership;
- measurable improvement;
- task success rate;
- reliability / latency / cost;
- failure taxonomy;
- regression suite;
- distributed systems;
- idempotency;
- auditability。
这意味着面试官不只会问“会不会 LangGraph”,还会问:
- Tool 已经执行成功,但 LLM 请求超时,如何防止重复执行?
- Agent 中途失败,如何恢复?
- 如何定义任务成功率?
- 如何区分检索错误和生成错误?
- 如何进行逐步发布和回滚?
- 如何限制 Agent 的权限?
- 如何监控成本、延迟和失败模式?
General Intelligence Company 的职位就明确要求 retry/backoff、idempotency、auditability、agent memory/context routing、OpenTelemetry/Datadog,以及离线和在线评测。4
特点二:Evaluation 是核心开发工作,不是上线后的附加项
很多美国职位把 Evaluation 直接写进核心职责:
Golden tasks
Regression suites
Behavior tests
Online metrics
A/B tests
Canary releases
Guardrail thresholds
Failure analysis
Amtex 的 Coding Agent 岗位甚至把 eval harness、failure taxonomy、tracing、metrics、alerts 和 release gates 列为硬性要求。5
特点三:安全与受限自主性比“完全自主”更受重视
企业 Agent 要接触 CRM、金融数据、身份系统、邮件、数据库和生产 API。美国岗位常明确要求:
- Human-in-the-loop;
- Guardrails;
- Audit Trail;
- Compliance;
- PII/PHI;
- Identity and Access Management;
- Constrained Autonomy;
- Safe Tool Use。
因此,优秀的 Agent Engineer 不是让 Agent“做得越多越好”,而是知道:
哪些动作可以自动执行,哪些必须审批,哪些必须被禁止。
特点四:美国职位未必总写某个框架,但会写底层能力
一些初创公司并不强制 LangChain 或 LangGraph,而是要求:
- Tool orchestration;
- Memory architecture;
- Retrieval;
- Evaluation;
- Retry/repair loop;
- Context routing;
- Backend reliability。
这类职位可能允许使用自研 Runtime、OpenAI Agents SDK、Google ADK、PydanticAI 或其他框架。因此,不能只背 LangGraph API,必须理解 Agent Runtime 的底层工程问题。
五、东京市场:Python、云和端到端交付最重要
5.1 东京 20 条 JD 技术频率
| 排名 | 技术方向 | 出现职位数 | 出现率 |
|---|---|---|---|
| 1 | Python | 19/20 | 95% |
| 2 | AWS、Azure、GCP 等云平台 | 18/20 | 90% |
| 3 | Agent、工具调用、工作流编排 | 16/20 | 80% |
| 4 | 后端、API、微服务 | 14/20 | 70% |
| 5 | RAG | 13/20 | 65% |
| 6 | 向量数据库、Embedding、搜索 | 11/20 | 55% |
| 7 | LangChain | 10/20 | 50% |
| 7 | LangGraph | 10/20 | 50% |
| 7 | 评测、可观测性、LLMOps | 10/20 | 50% |
| 10 | SQL、关系数据库、数据工程 | 8/20 | 40% |
| 11 | TypeScript / JavaScript | 7/20 | 35% |
| 12 | Prompt / Context Engineering | 6/20 | 30% |
| 13 | Docker / Kubernetes | 5/20 | 25% |
| 13 | PyTorch / TensorFlow / Hugging Face | 5/20 | 25% |
| 13 | 知识图谱 / GraphRAG | 5/20 | 25% |
| 16 | CI/CD、Terraform 等 IaC | 4/20 | 20% |
| 17 | MCP | 3/20 | 15% |
| 17 | Guardrails、HITL、安全、审计 | 3/20 | 15% |
| 17 | Go | 3/20 | 15% |
| 20 | 微调、模型部署、推理优化 | 2/20 | 10% |
| 21 | Java | 1/20 | 5% |
Future 的岗位明确列出 Python、LangChain、LangGraph、Amazon Bedrock 和 Azure OpenAI,并要求从业务流程重构、技术验证、RAG 精度改善到架构设计和开发的一体化能力。6
FLARETECH 的生成 AI 岗位进一步把 Python、RAG、向量数据库、LangChain/LangGraph、Evaluation、Guardrail、LLMOps、AWS 和 Docker 组合在一起,体现了东京市场对“从原型到生产”的要求。7
5.2 东京市场为什么把云平台排得这么高
东京样本中的云平台出现情况如下。同一个职位可能同时列出多个云,所以比例之和会超过 100%。
| 云平台 | 出现职位数 | 出现率 |
|---|---|---|
| AWS | 16/20 | 80% |
| Azure | 9/20 | 45% |
| GCP | 7/20 | 35% |
常见组合包括:
AWS Bedrock
AWS OpenSearch
S3
RDS PostgreSQL
ECS / Fargate
Lambda
Azure OpenAI Service
Azure AI Search
Vertex AI
Cloud Run
BigQuery
东京企业大量 AI 项目来自:
- 企业 DX;
- 生成 AI 咨询和 SI;
- 内部知识库;
- 客服与业务自动化;
- 金融、制造和人力资源;
- 既有 SaaS 产品增加 AI 功能。
这些项目必须接入企业数据和现有系统,因此“会使用模型”远远不够,招聘方更关心能否把系统部署、运维并交付给真实用户。
5.3 东京最看重的是 PoC 到生产,而不是纯研究
东京样本中:
后端/API/微服务:70%
云平台:90%
微调/推理优化:10%
这说明,在 AI Application / Agent / RAG 类岗位中,更受欢迎的是:
能把 AI 功能接入实际产品、完成 PoC、上线、监控和迭代的软件工程师。
nineDots 的东京 Applied AI 岗位要求 Python、CI/CD、Terraform、容器、RAG、Prompt、微调、LangChain、Pinecone、Hugging Face、LLMOps 和向量数据库,强调必须有把生成式 AI 从原型带到真实用户手中的经验。8
5.4 日本本土公司与美国公司日本分部的语言结构不同
语言不是技术栈,但在东京求职中是实际筛选条件。
日本客户型、SI 型和 FDE 型岗位
经常要求:
- 日语商务沟通;
- 日语需求定义;
- 日语技术文档;
- 与客户进行 PoC 和汇报;
- JLPT N2/N1 或相当能力。
TempestAI 的岗位明确要求能够使用日语进行需求定义和技术文档编写。9
国际产品团队和美国公司日本岗位
可能以英语为主要工作语言:
但面向日本客户的国际公司岗位仍可能要求双语。例如 Zoom 东京 Applied AI Engineer 要求日语和英语都熟练,工作内容包括在销售周期中把 AI Agent 从 PoC 部署到客户生产环境。13
所以东京市场可以粗略分为:
| 岗位类型 | 语言倾向 | 技术倾向 |
|---|---|---|
| 日本本土企业 / SI / 咨询 | 日语优先 | AWS、Python、RAG、客户交付 |
| 日本 AI 初创公司 | 日语或双语 | Python、Agent、LangGraph、快速 PoC |
| 国际产品公司 | 英语优先,日语可能不要求 | 系统设计、生产可靠性、Applied AI |
| 美国公司日本分部 / 客户交付 | 英日双语更有优势 | 美国式 Evaluation + 日本式客户交付 |
六、不同岗位名称实际在招什么
6.1 AI Application Engineer
核心任务是把模型能力做成业务功能。
常见要求:
- Python;
- FastAPI / Flask;
- LLM API;
- RAG;
- Tool Calling;
- 数据库与企业 API;
- 云部署;
- 测试与监控。
本质上是:
懂 AI 的后端/产品工程师。
6.2 AI Agent / Agentic AI Engineer
在 AI Application Engineer 的基础上,更强调:
- Agent Loop;
- Tool Use;
- Planning;
- Memory 与 State;
- LangGraph 或其他编排框架;
- Multi-Agent;
- Retry / Recovery;
- Human-in-the-loop;
- Guardrails;
- Evaluation。
本质上是:
设计和运行受控自主系统的后端/平台工程师。
6.3 RAG Engineer
更强调数据、搜索和效果优化:
- 文档解析;
- Chunking;
- Embedding;
- Vector DB;
- BM25 / Hybrid Search;
- Rerank;
- Metadata / ACL;
- Citation;
- Retrieval Evaluation;
- 数据更新与索引维护。
本质上是:
搜索工程、数据工程与 LLM 应用的交叉岗位。
6.4 Applied AI Engineer
美国和国际公司常用这个名称,通常要求端到端负责:
- 识别有价值的 AI 场景;
- 快速原型;
- 设计评测;
- 生产实现;
- 与产品和客户协作;
- 持续测量业务效果。
它通常比“纯算法工程师”更重视产品交付,比普通后端工程师更重视模型行为和评测。
6.5 Forward Deployed Engineer / AI Solutions Engineer
这类岗位在东京和美国公司日本分部很值得关注。
核心能力是:
客户问题
→ 需求澄清
→ 技术方案
→ PoC
→ 数据和系统集成
→ 生产上线
→ 培训与持续改进
除了技术,还要求:
- 沟通;
- 需求分析;
- 架构表达;
- 业务理解;
- 日语和/或英语;
- 对交付结果负责。
七、求职者应具备的能力模型
一个合格的 AI Application / Agent / RAG Engineer,能力不应该只是多个框架名称的集合,而应当形成下面八层结构。
第一层:生产级软件工程
必须具备:
- Python 类型注解;
- async / await;
- 测试;
- 日志和异常处理;
- API 设计;
- 并发与任务队列;
- 数据库;
- Git;
- 代码评审;
- 系统设计;
- 性能和可靠性基础。
第二层:LLM 应用基础
必须理解:
- Message 与 Context;
- Tool Calling;
- Structured Output;
- Token 和 Context Window;
- 模型选择与路由;
- Prompt / Context Engineering;
- Streaming;
- 缓存;
- 成本与延迟。
第三层:生产级 RAG
必须能够从零实现并调优:
- Ingestion;
- Parsing;
- Chunking;
- Metadata;
- Embedding;
- Retrieval;
- Rerank;
- Context Assembly;
- Citation;
- ACL;
- Evaluation。
第四层:Agent Runtime
必须理解:
- ReAct;
- State;
- Planning;
- Tool;
- Memory;
- Checkpoint;
- Interrupt;
- Retry;
- Idempotency;
- Human Approval;
- Sub-Agent;
- Long-running Task。
第五层:Evaluation 与 Observability
必须能够回答:
- 怎样定义成功?
- 怎样构建测试集?
- 怎样回归?
- 怎样定位错误属于检索、Prompt、模型还是工具?
- 怎样追踪 Agent 每一步?
- 怎样监控成本、延迟和失败率?
第六层:云与部署
至少掌握一套完整路径:
FastAPI
→ Docker
→ Container Registry
→ ECS/Fargate 或 Cloud Run
→ PostgreSQL
→ Object Storage
→ Vector/Search Service
→ Monitoring
→ Secrets
第七层:安全和治理
必须理解:
- Prompt Injection;
- Tool Permission;
- Secrets;
- PII;
- Audit Log;
- Tenant Isolation;
- Read/Write 权限分级;
- HITL;
- Sandbox;
- Rate Limit;
- Timeout;
- Idempotency。
第八层:业务和产品交付
企业不是为了“使用 Agent”而招聘,而是为了:
- 提高效率;
- 降低成本;
- 提升检索准确率;
- 自动化流程;
- 帮助客户决策;
- 增加产品收入。
求职者必须能把技术指标与业务价值连接起来。
八、为了在东京找工作,技术栈应如何排序
以下优先级同时考虑:
- 东京 JD 出现频率;
- 技术之间的前置依赖;
- 学习投入与求职回报;
- 是否能通过作品集证明;
- 是否具有跨中国、美国、日本市场的通用性。
P0:Python 生产级后端
推荐技术
Python 3.12+
uv
FastAPI
Pydantic v2
asyncio
pytest
Ruff
mypy / pyright
REST API
SSE / Streaming
WebSocket 基础
必须达到的能力
不是“会写脚本”,而是可以独立完成:
- 分层项目结构;
- Pydantic Schema;
- 依赖注入;
- 异步 API;
- Streaming;
- 单元与集成测试;
- 异常和重试;
- 日志与 Trace ID;
- PostgreSQL 事务;
- Redis/队列基础;
- 性能和并发排查。
为什么排第一
Python 在综合样本中达到 95%,东京达到 95%,美国样本达到 100%。它是 AI Application 岗位最稳定的共同语言。
P0:生产级 RAG
推荐技术
PostgreSQL + pgvector
OpenSearch
Qdrant
Redis
Embedding
BM25
Hybrid Search
Reranker
Metadata Filter
Citation
ACL
必须达到的能力
可以完整解释和实现:
文档解析
→ 切片
→ 索引
→ 召回
→ 重排
→ 上下文构造
→ 生成
→ 引用
→ 评测
还应当能够回答:
- Chunk 大小如何选择?
- 如何处理表格和 PDF?
- Dense Retrieval 为什么漏召回?
- BM25 和向量检索如何融合?
- Reranker 应放在哪里?
- 如何处理文档版本更新?
- 如何避免无权限文档被召回?
- 如何评测 Recall、MRR、NDCG、Faithfulness?
东京推荐数据库组合
优先掌握:
PostgreSQL/pgvector + OpenSearch
继续保留 Qdrant 作为独立向量数据库经验。
原因是 PostgreSQL 是通用企业基础设施,而 OpenSearch 与东京市场高频的 AWS、企业搜索和混合 RAG 高度匹配。
P0:LangChain v1 + LangGraph v1
LangChain v1 应重点学习
Model
Message
Tool
Structured Output
Middleware
Runtime Context
create_agent
MCP Integration
Provider Integration
不要把大量时间投入旧版 Chain API。
LangGraph v1 应重点学习
State
Node / Edge
Command
Checkpoint
thread_id
Interrupt
Resume
Retry
Subgraph
Store
Durable Execution
Idempotency
Human-in-the-loop
为什么两者必须组合
LangChain 解决模型、消息、工具和标准 Agent 接口。
LangGraph 解决生产 Agent 的:
- 状态;
- 中断;
- 恢复;
- 持久化;
- 审批;
- 长任务;
- 复杂工作流。
Deep Agents 应放在哪里
Deep Agents 目前没有在本次样本中形成高频招聘关键词。
合理顺序是:
LangChain v1 基础
→ LangGraph v1 Runtime
→ 生产级 Agent Engineering
→ Deep Agents
Deep Agents 值得学习其 Planning、Filesystem、Sub-Agent、Skills 和 Context Management,但不应替代对 LangGraph 的理解。
P0:AWS
东京云平台优先顺序建议:
AWS
>
Azure
>
GCP
AWS 首先学习
IAM
S3
Bedrock
OpenSearch
RDS PostgreSQL
ECS / Fargate
Lambda
CloudWatch
Secrets Manager
VPC 基础
推荐部署路径
FastAPI / LangGraph
↓
Docker
↓
ECR
↓
ECS Fargate
↓
RDS PostgreSQL
↓
OpenSearch
↓
S3
↓
Bedrock
↓
CloudWatch
Azure 的第二阶段重点是:
Azure OpenAI Service
Azure AI Search
Azure Container Apps
Azure Database for PostgreSQL
Azure Monitor
GCP 的第二阶段重点是:
Vertex AI
Cloud Run
Cloud SQL
BigQuery
Cloud Storage
P1:Evaluation、Observability 和 LLMOps
至少掌握
Golden Dataset
Prompt Versioning
Trace
Token Usage
Latency
Tool Success Rate
RAG Recall
Faithfulness
Agent Task Success Rate
Regression Test
Cost Monitoring
Failure Taxonomy
工具选择
不需要把所有产品都学一遍,选择一套深入:
Langfuse 或 LangSmith
+
OpenTelemetry
可以补充:
Ragas
DeepEval
Promptfoo
Phoenix
作品集必须展示
- 每次 Agent 运行的 Trace;
- 模型和 Prompt 版本;
- 每一步 Tool Call;
- Token、成本和延迟;
- 固定评测集;
- 修改检索或 Prompt 后的回归结果;
- 失败样本分类。
P1:Docker、CI/CD 与 Terraform
推荐顺序:
Docker
→ Docker Compose
→ GitHub Actions
→ Terraform
→ AWS ECS/Fargate
→ Kubernetes 基础
对大多数 AI Application 岗位,能够使用 Docker、Terraform 和 GitHub Actions 把服务稳定部署到 AWS,比深入背诵 Kubernetes 内部 API 更重要。
P1:Agent 安全、HITL 和可靠执行
必须掌握:
Prompt Injection
Tool Permission
Read/Write 权限分级
Human Approval
Secrets Management
PII
Audit Log
Timeout
Retry
Idempotency
Rate Limit
Tenant Isolation
Sandbox
推荐风险策略:
读取操作
→ 可以在明确范围内自动执行
写入操作
→ 根据风险请求批准
发送邮件、发布、部署、删除、付款
→ 必须明确审批或强策略限制
这部分在美国岗位中尤其重要,也是东京求职作品集非常有价值的差异点。
P2:MCP
MCP 在三个市场合计样本中的出现率约 15%,已经进入招聘语言,但还不是 P0 技能。
应该掌握:
- MCP Server / Client;
- Tool;
- Resource;
- Prompt;
- Transport;
- Auth;
- 凭据隔离;
- 权限控制。
必须理解:
MCP 解决工具和上下文接入的标准化,不负责 Agent 的状态机、可靠执行、评测和权限治理。
P2:TypeScript 与简单产品界面
东京样本中的 TypeScript/JavaScript 出现率为 35%。
不需要转型为专业前端工程师,但应能:
- 阅读和修改 TypeScript;
- 使用 React / Next.js;
- 做 Agent Chat UI;
- 展示 Streaming;
- 展示 Tool Call;
- 展示 Trace;
- 展示 Approval;
- 做简单管理后台。
推荐:
TypeScript
React
Next.js
基础 Tailwind CSS
P2:模型微调和推理优化
东京 AI Application 样本中只有约 10% 明确要求微调、推理优化或本地模型部署。
因此需要理解:
SFT
LoRA / QLoRA
DPO
Quantization
vLLM
SGLang
但不需要在求职初期投入数月训练模型,除非目标是:
- LLM Engineer;
- Model Engineer;
- ML Platform Engineer;
- Inference Engineer;
- Foundation Model Researcher。
对于 AI Application / Agent / RAG 岗位,生产级后端、RAG、评测和云部署通常有更高回报。
九、不同目标市场的定制技术栈
9.1 面向东京本土企业
Python
FastAPI
LangChain v1
LangGraph v1
RAG
PostgreSQL
OpenSearch
AWS Bedrock
ECS/Fargate
Docker
Terraform
Langfuse/OpenTelemetry
日语需求分析和技术说明
重点证明:
- 能从客户问题做 PoC;
- 能把 PoC 上线;
- 能写日语设计说明;
- 能解释成本、质量和风险;
- 能与既有系统集成。
9.2 面向美国公司日本分部
Python
System Design
Agent Runtime
RAG
Evaluation Harness
Observability
Guardrails
HITL
Distributed Systems
Cloud
CI/CD
英文技术沟通
日语客户沟通(客户型岗位)
重点证明:
- 生产 Ownership;
- 可量化的改善;
- 评测和回归;
- 安全边界;
- 失败恢复;
- 成本和延迟优化;
- 英文设计文档。
9.3 面向中国大陆企业
Python
FastAPI
LangChain/LangGraph
RAG
Milvus/Qdrant
国产模型 API
Dify/Coze/n8n
Docker/Kubernetes
vLLM/SGLang 基础
Java/Spring Boot/Spring AI 集成
私有化部署
重点证明:
- 国产模型适配;
- 企业知识库;
- 私有化;
- Java 业务系统集成;
- 模型部署;
- 交付速度。
十、最适合东京求职的完整技术栈
核心开发
Python 3.12+
uv
FastAPI
Pydantic v2
pytest
asyncio
REST / SSE
Ruff
mypy / pyright
Agent
LangChain v1
LangGraph v1
Structured Output
Tool Calling
Checkpoint
Interrupt / Resume
Human-in-the-loop
MCP
RAG 与数据
PostgreSQL
pgvector
OpenSearch
Qdrant
Redis
Hybrid Search
Reranker
Citation
ACL
Document Versioning
云与部署
AWS Bedrock
S3
OpenSearch
RDS
ECS / Fargate
IAM
CloudWatch
Secrets Manager
Docker
Terraform
GitHub Actions
评测与观测
Langfuse 或 LangSmith
OpenTelemetry
RAG Evaluation
Agent Evaluation
Regression Dataset
Cost / Latency Monitoring
展示层
TypeScript
Next.js
简单 Agent UI
差异化能力
Java / Spring Boot 企业系统集成
日语业务沟通
生产级 Agent 安全与审批
RAG 评测与回归
AWS 部署
英文技术文档
十一、学习时间如何分配
| 优先级 | 技术方向 | 建议投入占比 |
|---|---|---|
| P0 | Python、FastAPI、后端工程 | 20% |
| P0 | 生产级 RAG、检索、Rerank、评测 | 20% |
| P0 | LangChain v1、LangGraph v1 | 20% |
| P0 | AWS、Docker、部署 | 15% |
| P1 | PostgreSQL、pgvector、OpenSearch、Redis | 10% |
| P1 | LLMOps、Tracing、Evaluation | 7% |
| P1 | Agent 安全、HITL、幂等性 | 5% |
| P2 | MCP、TypeScript、简单前端 | 3% |
一个可执行的 20 周路线
第 1~4 周:生产级 Python 后端
交付物:
- FastAPI 项目;
- PostgreSQL;
- 异步 API;
- 测试;
- Docker;
- Streaming;
- 日志和错误处理。
第 5~8 周:生产级 RAG
交付物:
- PDF/Word/HTML 摄取;
- pgvector 或 Qdrant;
- BM25 + Dense Hybrid;
- Reranker;
- Citation;
- Metadata Filter;
- 评测数据集。
第 9~12 周:LangChain v1 与 LangGraph v1
交付物:
- Tool Calling Agent;
- StateGraph;
- Checkpoint;
- Interrupt;
- Human Approval;
- Retry;
- 多步骤任务;
- 可恢复运行。
第 13~16 周:AWS 和部署
交付物:
- Docker 镜像;
- ECS/Fargate;
- RDS;
- S3;
- OpenSearch;
- Bedrock;
- Terraform;
- GitHub Actions;
- CloudWatch。
第 17~20 周:评测、安全和求职包装
交付物:
- Langfuse/OpenTelemetry Trace;
- RAG Regression;
- Agent Task Success Rate;
- Prompt Injection 测试;
- Tool 权限;
- Audit Log;
- 日英双语 README;
- 系统设计文档;
- 演示视频。
十二、最值得做的求职作品集
与其做五个简单聊天机器人,不如做一个完整的:
企业级日英双语 RAG + Agent 平台
12.1 架构
PDF / Word / HTML / 企业数据
↓
解析、清洗、切片、版本管理
↓
OpenSearch + pgvector/Qdrant 混合检索
↓
Reranker
↓
带页码、来源和权限的回答
↓
LangGraph Agent
↓
GitHub / Gmail / Calendar / MCP Tools
↓
写操作 Human Approval
↓
PostgreSQL Checkpoint
↓
Langfuse / OpenTelemetry
↓
AWS 部署
12.2 必须实现的能力
- 日文和英文文档;
- 文档版本管理;
- ACL 权限过滤;
- Hybrid Search;
- Reranker;
- Citation;
- LangGraph Checkpoint;
- 中断与恢复;
- 写工具审批;
- 幂等性;
- 多用户隔离;
- Trace;
- Evaluation;
- Docker;
- Terraform;
- GitHub Actions;
- AWS 架构图。
12.3 必须量化的指标
不要只展示界面,应展示:
Retrieval Recall@K
MRR / NDCG
Answer Faithfulness
Citation Accuracy
Agent Task Success Rate
Tool Failure Rate
P95 Latency
Token Cost
Recovery Success Rate
12.4 README 至少应回答
- 为什么选择这个架构?
- 为什么使用 OpenSearch + pgvector/Qdrant?
- 怎样防止越权检索?
- 如何区分检索失败和生成失败?
- 如何恢复中断的 Agent?
- 如何防止重复写操作?
- 怎样评测系统?
- 怎样部署?
- 当前限制是什么?
- 下一步如何扩展?
这一个项目可以覆盖东京高频要求中的大部分技术:
Python
FastAPI
AWS
Agent
RAG
LangChain
LangGraph
向量搜索
SQL
Docker
Terraform
CI/CD
Evaluation
Observability
MCP
Security / Approval
十三、面试时必须能够回答的问题
Python 与后端
- async/await 什么时候真正提高吞吐量?
- LLM Streaming API 如何实现?
- FastAPI 服务如何处理超时、取消和重试?
- 如何设计幂等接口?
- 如何处理长时间 Agent 任务?
RAG
- 为什么只用向量搜索不够?
- Chunking 如何影响召回?
- 如何设计 Hybrid Search?
- Reranker 的输入和输出是什么?
- 如何评测 Retrieval?
- 如何实现 Citation 和 ACL?
- 文档更新后如何避免旧版本污染?
Agent
- Tool Calling 与 Workflow 有什么区别?
- LangChain 与 LangGraph 的关系是什么?
- Checkpoint 保存什么?
- Interrupt 后如何继续?
- Tool 已执行但节点失败怎么办?
- 什么时候使用 Multi-Agent?
- 如何避免 Agent 无限循环?
- 如何限制工具权限?
Evaluation
- Agent 成功率怎么定义?
- 如何建立 Golden Dataset?
- 如何做 Prompt 回归?
- 如何定位失败属于模型、检索还是工具?
- 如何做离线评测和线上监控?
- 如何设置 Release Gate?
云和生产
- 为什么选择 ECS/Fargate,而不是 Lambda 或 Kubernetes?
- Secrets 如何管理?
- 日志、Trace 和 Metrics 怎样关联?
- 如何控制成本?
- 如何做滚动发布和回滚?
- 如何设计多租户隔离?
十四、常见学习误区
误区一:同时学习十个 Agent 框架
不建议同时深入:
LangGraph
CrewAI
AutoGen
Agno
PydanticAI
Google ADK
OpenAI Agents SDK
Deep Agents
Semantic Kernel
Strands
应该先掌握:
LangChain v1
+
LangGraph v1
+
Agent Engineering 原理
再根据公司技术栈迁移。
误区二:把 Prompt Engineering 当成独立职业壁垒
Prompt 很重要,但企业更看重:
- Prompt 是否可版本化;
- 是否可评测;
- 是否可回归;
- 是否有结构化输出;
- 是否能与 Tool、RAG、业务规则结合;
- 是否能控制成本和失败率。
误区三:只会 Dify 或 Coze
低代码平台适合 PoC,但不能替代:
- Python;
- API;
- 数据库;
- 状态管理;
- 测试;
- 权限;
- 部署;
- 可观测性。
误区四:过早投入模型微调
对于 AI Application、Agent 和 RAG 岗位,先把:
后端
RAG
Agent
Evaluation
Cloud
做到生产级,通常比先训练模型更有求职价值。
误区五:只做能聊天的作品集
聊天界面不能证明:
- 可靠性;
- 评测;
- 安全;
- 系统设计;
- 部署;
- 业务价值。
作品集必须展示失败处理、指标和架构取舍。
十五、结论
2026 年的 AI 应用就业市场已经形成了一条相当明确的主线:
企业真正需要的不是“会调用模型的人”,而是“能够把不确定的模型能力变成稳定、可评测、可审计、可部署业务系统的人”。
中国大陆、美国和东京的共通技术底座是:
Python
+
RAG
+
Agent
+
后端/API
+
向量检索
+
Evaluation/Observability
+
Cloud/Deployment
区域差异则是:
- 中国大陆更重视国产模型、私有化、Java 业务系统集成和推理部署;
- 美国更重视评测、可靠性、Guardrails、系统设计和生产 Ownership;
- 东京更重视 Python、AWS、后端、客户交付,以及从 PoC 到生产的完整能力;
- 美国公司日本分部通常要求同时满足美国式工程质量与日本市场的沟通、交付要求。
如果目标是在东京获得 AI Application Engineer、AI Agent Engineer 或 RAG Engineer 工作,最优先的路线不是收集更多框架名称,而是成为这样的人:
能够使用 Python、LangGraph、RAG 和 AWS,把 AI Agent 安全、稳定、可评测地部署到生产环境,并能用日语或英语向团队和客户解释设计取舍。
附录 A:本次调研的代表性公开职位样本
以下链接用于复核技术趋势。职位可能随时间关闭、重新发布或修改。
A.1 中国大陆
- 武汉菱电:Python 智能体工程师(AI 应用)
- 润建股份:AI 应用开发工程师
- 深圳中迈:Python(RAG/AI Agent)
- 重庆典名:AI 智能体研发工程师
- 辽宁联微宜众:AI Agent 开发工程师
- 中科软:AI 大模型应用工程师
- 博雅创智:AI 算法工程师
- 上海宽文是风:AI 开发工程师
- 华领控股:Python 开发工程师—AI 应用方向
- 中天控股:大模型应用开发工程师
- 中创实:大模型应用工程师
- 深圳:AI Agent 智能体工程师
- 立邦中国:AI Agent 开发工程师
- 上海:AI Agent 开发工程师
- 宁波国际物流:AI 应用高级开发
- 北京华龙宏达:AI 应用开发工程师
- 科大国创:AI 开发工程师
- 深德科:AI 应用开发工程师
- 浙江容途:AI 应用工程师
- 广电计量:AI Agent 开发工程师
A.2 美国
- EXL:Agentic AI Engineer
- Amtex Systems:AI Agent Engineer
- Joveo AI:AI Agent Engineer
- Lumos:AI Agent Engineer
- QODE:AI / Agent Engineer
- Ditto.ai:Applied AI Engineer
- Curie:AI Engineer
- The General Intelligence Company of New York:Applied AI Engineer—Agent
- Pulsora:Applied AI Engineer—US
- BJAK:Applied AI Engineer—US
- Rowspace:Applied AI Engineer
- Amigo:Applied AI Engineer
- CodeRabbit:Applied AI Engineer
- Sapien:Applied AI Engineer
- Taktile:Senior Applied AI Engineer
- HackerOne:Staff Software Engineer, Applied AI
- Nimble Gravity:Senior AI Engineer
- SBT Global:Senior Generative AI Engineer
- Woongjin:Senior Gen AI Engineer
- Leorna:Lead AI Architect and Engineer
A.3 东京及日本市场
- Future:AI・LLM Engineer
- renue:AI・LLM Engineer
- FLARETECH:生成 AI Engineer(LLM/RAG)
- kubell:AI Solution Engineer
- Mindia:Python × LLM Full-stack Engineer
- Upgrade:AI Engineer—Agent/RAG
- Algomatic:AI/ML Engineer—AI Agent
- Rakus:AI Development Tech Lead
- CARTA HOLDINGS:AI Engineer
- Genie:LLM/RAG Backend Engineer
- Emuni:AI/LLM Engineer
- TempestAI:LangGraph Multi-Agent Engineer
- HEROZ:Backend Engineer—AI Agent
- Robert Half:AI Engineer(RAG)
- BJAK:Applied AI Engineer—Japan
- nineDots:Senior Applied AI Engineer
- Cookpad:Principal Applied AI Engineer
- Kaigen:AI Software Development Engineer
- Zoom:Applied AI Engineer—Tokyo
- ExaWizards:AI Solution Engineer