如何在 2026 年成为 AI 工程师。
无需 CS 学位。
无需 bootcamp。
今天甚至无需知道 transformer 是什么。
没人告诉你的是：
现在正在招人的公司，不需要懂数学的人。
他们需要的是能把系统做到扛得住生产环境的人。
这两者是有区别的。
套壳 chatbot 不是系统。
一次 tool call 不是 agent。
会用 LangChain 不等于懂 harness 工程。
这两件事之间的差距，差不多就是 15 万美元的年薪。
这就是跨过这道坎的精确路线图。
存下来。你会读两遍。
先说残酷的真相
现在大多数在做 AI 的开发者，做的都是玩具。
他们用几个 prompt 把 GPT 一包，管它叫「AI 产品」，然后纳闷为什么没人付费。
市场上充斥着对 LLM 的薄薄一层封装。
这些不是生意。它们只是功能点，等着被大厂 Sherlock 掉（把你的功能并进自家平台，顺手让你出局）。
2026 年公司真正愿意付钱买的是这些：
→ 周五凌晨两点也不会崩的 agent
→ 你能度量、能证明它没有退化的系统
→ 能让同一个模型表现提升 86% 的 harness
最后这一点不是虚构。
Anthropic 拿同一个模型（Opus 4.5）跑了两套不同的 harness。
→ Claude Code harness：CORE benchmark 上 78%
→ Smolagents harness：CORE benchmark 上 42%
同一个模型。不同的 harness。36 个百分点的差距。
harness 就是这份工作本身。
AI 工程师在 2026 年实际上做什么
不是写 prompt。不是挑模型。
AI 工程师的活儿是构建并运维模型周围的那套系统。
也就是说：
→ 设计 agent loop 和 tool dispatch（工具分发）
→ 工程化 context —— 决定每一步往模型面前塞哪些 token → 写出模型真的会正确选用的 tool
→ 为生产流量加上 memory、durability（持久性）和 sandboxing（沙箱化）
→ 接好 evals 和 CI 回归门，让「更好」变成可度量的
→ 交付能扛住真实用户和真实成本的 agent
每个 agent 工程师都需要的四个 context 原语（primitive）：
Write（写） —— 草稿区，agent 读写的记忆文件 Select（选） —— 在使用点做检索，而不是一上来就全塞进去 Compress（压） —— 在 context window 用到 85-95% 时做摘要 Isolate（隔离） —— 拥有各自独立 context window 的子 agent
这叫 context engineering（上下文工程）。prompt engineering 作为一项独立技能已经死了。context engineering 取代了它。
六阶段路线图
全职的话 17 周。业余兼职的话 40 周。
每个阶段都有一个具体项目。不交付东西，阶段就不算结束。
第 0 阶段：建立正确的心智模型（第 1-2 周）
先别急着写一行 agent 代码。
大多数新手跳过这一步。他们一头扎进教程，然后写出一堆自己都搞不懂、一崩就抓瞎的代码。
在做任何事之前，有三件事必须烂熟于心：
1. Workflow vs Agent
workflow 有一条你自己写死的控制流。agent 在一个 loop 里自己做控制流决策。
明明需要 workflow 却去造 agent，成本要高 10 倍，崩的频率还要翻倍。
2. 五种 workflow 模式（来自 Anthropic）
→ Prompt chaining：把一次调用的输出传给下一次
→ Routing：不同任务用不同模型
→ Parallelization：多个任务同时跑
→ Orchestrator-worker：一个大脑，多只手
→ Evaluator-optimizer：生成 → 评判 → 改进
3. harness
harness 是夹在你和模型 API 之间的那一层。
把它想成一个操作系统：
→ 模型 = CPU（原始算力）
→ RAM = context window
→ OS = harness
→ Apps = 你的 agent 的 skills
OS 决定了 CPU 实际能干什么。harness 决定了模型实际能干什么。
第 0 阶段项目： 写一份 2 页的文档 —— 用你自己的话 —— 把这些讲清楚：workflow vs agent、五种 workflow 模式、四个 context 原语、orchestrator-worker 模式。
如果你不看资料就写不出来，说明你读得还不够仔细。
第 1 阶段：从零造出你的第一个 agent（第 3-5 周）
把一个 agent 写两遍。
第一遍：用原始的 Anthropic SDK。约 100 行 Python。第二遍：用 Claude Agent SDK。
然后去感受其中的差别。
第 1 遍 —— 裸 loop
agent loop 并不神奇。
- 用 messages 和 tools 调用模型
- 解析出 tool_use 块
- 执行 tool
- 追加 tool_result
- 循环直到 stop_reason = end_turn
自己用 100 行以内把这个写出来。
一旦写出来，每个框架你都能读懂了。
给它 3 个 tool：→ web_search → read_file → write_file
拿一个研究任务跑跑看。把 trace 的每一步都读一遍。
第 2 遍 —— 同一个 agent，跑在 Claude Agent SDK 上
Claude Agent SDK 就是驱动 Claude Code 的那套 harness。
加上：
→ 写好项目约定的 CLAUDE.md
→ 一个 Skill（一个定义「research-summary」输出格式的文件夹）
→ 一个 PostToolUse hook，自动格式化 agent 写的每个文件
→ 一个通过 Task tool 派生出来的子 agent
然后写 200 字回答：「harness 免费给了我哪些，是我在第 1 遍里自己手写的？」
第 1 阶段项目： 一个每日简报 agent。读你的 Markdown 笔记 + RSS feed。每天早上把一份摘要简报写到磁盘上。跑它一周。看着它失败。修好它。
第 2 阶段：用合理的架构造一个真正的 agent（第 6-9 周）
现在你在 LangGraph + Deep Agents 上来构建。
这是生产级技术栈。
LangGraph 给你：
→ 状态机（节点 + 边）
→ PostgresSaver checkpointing（任何进程被杀都能存活）
→ 时间旅行调试（回退到任意一步）
→ Human-in-the-loop 中断
→ 通过 LangSmith 实现一等公民的可观测性
Deep Agents（LangChain 打包好的 harness）给你：
→ Planning middleware
→ 虚拟文件系统
→ 子 agent 派生
→ 自动 context 压缩
→ Skills
关键概念：middleware
middleware 是你不用 fork 就能定制一个打包好的 agent 的方式。
四个要紧的 hook：
→ before_agent —— 在 loop 开始前运行
→ wrap_model_call —— 包裹每一次 LLM 调用
→ before_tools —— 在任何 tool 执行前运行
→ after_tools —— 在任何 tool 执行后运行
第 2 阶段项目：研究分析 agent
输入：一个研究问题
架构：
→ Lead agent 做规划，把 TODO 列表写进虚拟文件系统
→ 并行派生 3 个 search 子 agent（隔离 context）
→ 子 agent 把结果写进文件，把简短摘要返回给父节点
→ Citation 子 agent 核实论断
→ Writer agent 产出带内联引用的最终 Markdown
→ 状态通过 PostgresSaver 持久化 —— 杀掉进程，从断点继续
→ Human-in-the-loop 中断：token 花费超过 1 美元前先请求确认
把一个 LangSmith trace URL 和你的 README 一起交出来。
第 3 阶段：自己造出 harness 这一层（第 10-13 周）
这是整条路线图里杠杆率最高的一个阶段。
别再用打包好的 harness 了。自己造一个薄的出来。
在你亲手造过一次之前，你永远不会在生产环境里做出正确的 harness 取舍。
一个现代 harness 的 10 个组件：
-
Loop control —— 驱动 模型 → tools → 模型 的那个 while 循环
-
Tool dispatch —— 注册表、schema 校验、并行调用、重试
-
Context management —— system prompt 组装、在窗口 85% 处压实
-
Persistence —— 每个节点都 checkpoint 状态，以便 resume、rewind、fork
-
子 agent 编排 —— 隔离 context 的子节点，把压缩后的摘要传回
-
Skills 与渐进式披露 —— 只在相关时才加载能力
-
Hooks —— PreToolUse、PostToolUse、PreCompact、Stop
-
可观测性 —— 为每次模型调用、tool 调用、子 agent 调用打 OTEL span
-
Sandboxing —— 代码在一个模型永远拿不到凭证的容器里执行
-
Auth brokering（凭证代理）—— 凭证永远不进入模型的 context
第 3 阶段项目： 用约 1500 行 Python 写一个 mini-harness。
必须包含：
→ 从 @tool 装饰器生成 tool 注册表，并自动生成 JSON-schema
→ CLAUDE.md 风格的 system prompt 加载器
→ SKILL.md 渐进式披露加载器
→ 带隔离 context 的子 agent 派生原语
→ 文件系统卸载：任何超过 20K token 的 tool 结果
→ 写到磁盘，在 context 里用「路径 + 10 行预览」替换掉
→ 在 context window 85% 处自动压缩
→ 可插拔的 hook 系统（pre_tool、post_tool、stop）
→ OpenTelemetry 追踪
→ 持久化恢复：每步之后存到 SQLite，按 run ID 重新加载
真正的交付物：一篇 1000 字的复盘，把你的 mini-harness 和 Claude Agent SDK、Deep Agents 做对比。你做对了什么。你砍掉了什么。你下次会怎么改。
第 4 阶段：造出 eval 和回归 harness（第 14-17 周）
没有这个，每一次「改进」都只是凭感觉。
这是大多数工程师卡住的地方。
他们能造出一个很棒的 agent。但他们说不清自己下一次改动到底让它变好了还是变差了。
你必须实现的四种 eval 类型：
1. Single-turn evals给定这个输入，输出对不对？最便宜。尽可能用确定性的打分器。持续跑。
2. Trajectory evalsagent 是否用正确的参数、按正确的顺序调用了正确的 tool？测 single-step、full-turn 和 multi-turn 三种变体。
3. LLM-as-judge用于开放式输出：研究报告、code review、解释说明。每周用人工打分的样本来校准。
4. End-state evals用于有状态的 agent：数据库写对了吗？该改的文件改了吗？把最终的环境状态和 ground truth 对比。
关于 eval 的一个让人不舒服的真相：
模型能察觉出自己正在被评测。它们在 eval 输入上的行为会不一样。
把你的 eval 套件设计成能防住这一点。用真实的生产查询，别用合成的。
第 4 阶段项目： 围绕你第 2 阶段的 agent 造一套回归 harness。
→ Golden 数据集：30-50 个人工打分的研究问题（3 个难度等级）
→ 给事实型查询配确定性打分器
→ 给开放式问题配带 5 项标准评分表的 LLM-as-judge
→ Trajectory eval：agent 是否做了规划、派生了 2 个以上子 agent、引用了来源、在预算内完成？
→ 接进 GitHub Actions：如果 golden 集通过率掉了 3 个点以上就阻止合并
→ 生产采样：每晚自动给 1% 的线上 trace 打分
第 5 阶段：生产环境加固（永远）
这个阶段永无止境。
五件永远重要的事：
1. 成本纪律
→ 缓存你的 CLAUDE.md、system prompt 和 tool 定义 —— 最高能省 90%
→ 按难度路由：简单回合用 Haiku，大部分任务用 Sonnet，硬推理用 Opus
→ 非实时的活儿用 Batch API：打五折
→ 多 agent 烧掉的 token 大约是单 agent 的 15 倍 —— 只在价值足以跨过这道门槛时才跑它
2. 延迟
→ 永远并行调用 tool —— Anthropic 自家研究 agent 的 system prompt 里就明明白白写着「你 MUST 使用并行 tool call」
→ 把部分输出流式推到 UI
→ 子 agent 扇出：一个 60 步的串行 agent
→ 10 步的 lead + 5 个并行的 10 步子 agent
3. 安全与沙箱化
→ 所有代码执行都放在沙箱里（Modal、E2B）：永远不要在你的主进程里 exec() 模型的输出
→ 凭证在模型 context 之外做代理：模型永远看不到它用的 API key
→ 任何不可逆的操作都配 Human-in-the-loop 中断
4. 监控与漂移
→ 对这些告警：每请求的 token 成本、tool 调用失败率、LLM-as-judge 分数、p95 延迟
→ 每次模型升级后都重新给 eval 定基线 —— harness 里编码了一堆关于「模型做不到什么」的假设，而这些假设会过时
5. 韧性
→ 任何运行超过 60 秒的 agent 都上持久化执行（Inngest、Temporal、PostgresSaver）
→ 每个节点之后都 checkpoint
→ rewind 和 fork 应该永远是可行的
五个生产级项目（挑一个，这个周末就开干）
这些按复杂度排序。
它们证明的正是公司真正想看到的东西。
项目 1：用 SLM 打造的 AI 手机应用
等级：入门 | 证明：边缘 AI + 资源优化
用小语言模型（SLM）造一个离线优先的手机应用。零 API 成本。完全隐私。
它不平凡的地方在于：
→ 按需懒加载模型，在内存压力下卸载
→ 带语义分块的滑动 context window
→ 老设备上 4-bit 量化，新设备上 8-bit
→ 批量推理以减少电池唤醒周期
为什么重要：你证明了自己懂资源约束和设备级 AI。你不只是在调一个 API —— 你在管理内存压力和量化。
项目 2：自我改进的编码 agent
等级：进阶 | 证明：Agentic Loop + 生产级调试
造一个会写代码、跑测试、并从失败中学习的 agent。代码不能跑通它就不停。
它不平凡的地方在于：
→ 规划 → 执行 → 测试
→ 带最大迭代上限的 Reflect loop
→ 每个任务一个隔离的执行环境，并带资源限制
→ 记忆分层：短期（最近 5 次迭代）、长期（成功的模式）、失败记忆（错误特征 + 解法）
→ 执行前做静态分析 —— 检测危险操作
为什么重要：引入了 agentic loop。展示出你懂生产级调试和迭代式打磨。
项目 3：视频剪辑界的 Cursor
等级：高级 | 证明：多模态 AI + 复杂 tool 集成
fork 一个开源剪辑器（Shotcut），造一个能理解剪辑意图的 AI agent。
用户说「把这段弄得有电影感」。agent 来处理剪切、转场和调色。
它不平凡的地方在于：
→ Vision 模型分析每一帧 + audio 模型分析对白
→ 意图翻译：「电影感」
→ 转成具体参数（节奏、LUT、焦点模拟）
→ 通过帧差分析做场景检测
→ 增量预览 —— 只重新渲染受影响的片段
为什么重要：多模态 AI + 复杂 tool 集成。让你从 99% 的 chatbot 制造者里脱颖而出。
项目 4：个人 Life OS agent
等级：专家 | 证明：深度 context + 隐私优先架构
造一个管理你的日历、财务和健康的 agent。提前几个月做规划。通过分析睡眠模式和会议密度来检测 burnout。
它不平凡的地方在于：
→ 从日历、财务、健康、通讯实时摄入数据
→ 实体与关系的个人知识图谱
→ 每 6 小时跑一次的后台线程，检查异常
→ 价值对齐：用户陈述优先级（家庭 > 工作）—— 每条建议都拿这个来校验
→ 所有数据静态加密，密钥由用户掌控
为什么重要：需要精细的 context 管理和有伦理意识的 AI 设计。展示了隐私优先的生产级架构。
项目 5：自主企业工作流 agent
等级：大师 | 证明：生产级编排
一个端到端跑业务工作流的 agent。
监控 Slack/Jira → 规划执行 → 派发任务 → 带完整审计日志地汇报结果。
它不平凡的地方在于：
→ 事件驱动：监听 Slack、Jira、邮件、监控系统
→ 多 agent 派发：orchestrator
→ 通讯 agent、数据 agent、分析 agent、文档 agent
→ 自愈：指数退避、熔断器、自动重试决策
→ 不可变审计日志：每个动作、谁授权的、结果是什么
→ Human-in-the-loop：关键工作流上，agent 在执行前先提出方案
为什么重要：把编排、安全和可观测性合进一个可扩展的系统。这是收尾压轴的作品集。
技术栈（实际该学什么）
框架：LangGraph 1.0 + Deep Agents
为什么不用 CrewAI、AutoGen 或 OpenAI Swarm？
→ CrewAI：demo 跑得最快，生产环境里脆弱。拿来打 hackathon 用。
→ AutoGen：已并入 Microsoft Agent Framework。未来不明朗。
→ OpenAI Swarm：按 OpenAI 自家 README 的说法，明确「未达生产可用」。
LangGraph 给你：状态机 + PostgresSaver 持久性 + 时间旅行调试 + 对 OTEL 友好的可观测性 + 模型无关。
harness 参考：Claude Agent SDK
研究它。用它。它和 Claude Code 是同一套 harness。
CLAUDE.md + Skills + 子 agent + hooks + 文件系统即记忆。
2026 年其他所有 harness 都在向这些原语收敛。
可观测性：挑一个
→ LangSmith：如果你活在 LangGraph 里
→ Braintrust：如果你想要框架无关的 CI 门控（249 美元/月，统一价）
→ Arize Phoenix：如果你想要开源 + OTEL 原生
2026 年可以跳过的：
→ OpenAI Swarm —— 未达生产可用（可以用 Kimi Agent Swarm）
→ OpenAI Assistants API —— 2026 年中将停用
→ 在你度量出真实的召回问题之前就自己造向量库
→ 无代码 agent 平台，除非是用完就扔的
Benchmark 数字（2026 年 5 月）
SWE-bench Verified（编码任务）：→ Claude Opus 4.7：约 87.6% → GPT-5.5：约 88.7%
GAIA（通用 agent 任务）：→ Claude Sonnet 4.5 领先，74.6%
τ-bench（客服 agent）：→ Claude Mythos Preview：89.2%
关键洞察：同一个 benchmark，不同的 harness = 10 到 36 个点的摆动。
模型的分量不如 harness。
17 周时间线
第 2 周 → 第 0 阶段完成。你能用大白话讲清楚 harness 是什么。
第 5 周 → 第 1 阶段完成。带一个 Skill、一个 hook、一个子 agent 的 Claude Agent SDK agent 交付。
第 9 周 → 第 2 阶段完成。带 PostgresSaver 持久性和 LangSmith trace 的 LangGraph deep-agent 跑起来。
第 13 周 → 第 3 阶段完成。1500 行的 mini-harness 写完并写好文档。
第 17 周 → 第 4 阶段完成。golden 数据集、CI 门控、一次通过 Inspect 发布的 benchmark 跑分。
第 17 周以后 → 第 5 阶段。永远。
每周兼职 10-15 小时：所有时间乘以 2.5 倍。
让人不舒服的真相
大多数人会读完这篇然后什么都不做。
他们会收藏它。说一句「好文章」。然后回去继续做套壳。
2026 年残酷的真相：
→ 可被替代的：做薄薄的 GPT 套壳 → 开不掉的：交付带 eval 和持久性的自主系统
这两者之间的差距，是 5 个项目和 17 周的专注投入。
现在有 57% 的团队已经把 agent 放进了生产环境。
其中 89% 接好了可观测性。
质量是头号障碍（32% 的团队提到这一点）。
这意味着，整个领域的瓶颈卡在能造 eval 和 harness 的工程师身上。
而不是卡在能调 LLM API 的工程师身上。
这就是那个职位空缺。
收尾
这份路线图不会在 17 周里把你变成首席 AI 工程师。
它会把你变成一个能构建并交付、扛得住生产流量的 agent 系统的人。
而这恰好就是公司现在正在付钱买的东西。
下面是我希望你接下来做的：
1. 挑一个项目。 如果你是新手，从项目 1 开始。如果你已经在交付代码了，从项目 5 开始。开干就行。
2. 这个周末就把它做出来。 市场奖励的是交付，不是研究。
3. 把一切都记录下来： 你的架构决策、你的失败与恢复、你的自我纠错 loop。
4. 公开地做（build in public）。 你交付的时候 @ 我 —— 我会帮你放大。
到下个月，90% 的人会什么都没做。他们还在做同样的套壳。
另外 10% 会交付出真东西。他们会拿到面试、offer 和职业杠杆。
选择很简单：
成为公司抢着想招的那个架构师。或者变得过时。
专业能力是唯一剩下的工作保障。生产系统是唯一重要的作品集。
现在，去造一个能在现实里活下来的东西。
回复你要开始做哪个项目。每条回复我都看。
→ 转发分享给你的人脉圈
→ 关注 @sairahul1，看更多这样的拆解