← 返回文章列表
查看 ↗

最近AI coding让我觉得自己又行了,那么没有计算机背景,怎么成为一个AI工程师呢?

坦率的讲,我最近被一个数字吓到了。57%的团队现在已经在生产环境里跑着AI agent了。然后我看了一眼招聘市场,发现一个特别有意思的错位——大量的人在学怎么写prompt,大量的人在问怎么调API,但真正稀缺的人,是那些能让agent在凌晨两点不出事的工程师。这两个技能之间,差着大概15万刀的年薪。

深夜办公室里,一位年轻程序员正对着电脑屏幕露出自信微笑,屏幕上是一个稳定运行的AI agent系统,周围漂浮着各种代码符号和简报文档,窗外是城市夜景,暗示凌晨加班但系统稳如泰山的意境


坦率的讲,我最近被一个数字吓到了。

57%。

57%的团队现在已经在生产环境里跑着AI agent了。

然后我看了一眼招聘市场,发现一个特别有意思的错位——大量的人在学怎么写prompt,大量的人在问怎么调API,但真正稀缺的人,是那些能让agent在凌晨两点不出事的工程师。

天平两端分别是大量prompt学习者和稀缺的生产级agent工程师,暗示招聘市场的错位

这两个技能之间,差着大概15万刀的年薪。

今天聊一个我研究了挺久的东西,怎么在没有CS学位、没有bootcamp、连transformer是啥都懒得查的情况下,成为一个AI工程师。

说真的,这个话题我想聊很久了。


先泼一盆冷水

大多数现在在做AI开发的人,说实话,在做玩具。

套一个GPT,加几个prompt,做成一个chatbot wrapper,然后管它叫AI产品。

然后呢?

然后就奇怪为什么没人付费。

市场上全是这种薄薄的LLM外衣。这些不是business,是等着被Big Tech一波带走的feature。

公司真正在付钱买的,是这样的能力:

能扛住周五晚上两点突发流量的agent。

能测量、能证明没有在退步的系统。

能让同一个模型性能提升86%的harness。

对,你没看错,86%。

Anthropic做过一个实验,同一个模型(Opus 4.5),跑了两个不同的harness。

Claude Code harness:78% on CORE benchmark。

Smolagents harness:42% on CORE benchmark。

同一个模型,不同的harness,差了36个点。

这36个点,就是你存在的价值。


AI工程师到底是干嘛的

不是写prompt。

不是选模型。

是在模型外面建一整套系统,让这个模型在生产环境里能跑、能用、能被人依赖。

具体来说就是这些:

设计agent loop和tool dispatch。

工程化context——在每一步,到底有哪些token送到模型面前。

写能让模型正确调用的工具。

给生产流量加上memory、durability、sandboxing。

接evals和CI regression gates,让「变好」这件事变得可测量。

把能扛住真实用户和真实成本的agent交付出去。

这里有个核心概念得先搞清楚。

Context Engineering。

Prompt engineering作为独立技能,已经死了。

现在你需要的是context engineering,也就是怎么管理模型看到的上下文。

有四个基本原语:

Write——让agent读写scratchpads和memory文件。

Select——在需要的时候做retrieval,而不是一开始就往里灌。

Compress——在context window用到85%到95%的时候做summarization。

Isolate——用sub-agent,每个sub-agent有自己的独立context window。

这四件事,就是context engineering的核心。


17周的路线图

全职学17周,兼职学40周。

每个阶段一个具体项目。没有项目不进入下一阶段。

说真的,这个节奏我很喜欢。学东西最怕的就是光看不练。

Phase 0:先建正确的思维模型(第1-2周)

先别写一行agent代码。

大多数初学者跳过了这一步,直接看教程,然后写出来的代码一旦出问题就完全无法debug。

三件事必须在动手之前搞透:

1. Workflow vs Agent

Workflow的控制流是写死的,agent的控制流是它自己在loop里做决策的。

该用workflow的时候写了agent,成本多10倍,出bug概率多一倍。

2. 五个workflow patterns

这个来自Anthropic,我直接列出来:

Prompt chaining:上一个调用的输出传给下一个。

Routing:根据任务类型分发给不同模型。

Parallelization:多个任务同时跑。

Orchestrator-worker:一个大脑,多个执行者。

Evaluator-optimizer:生成→判断→改进。

3. Harness是什么

Harness是模型API和你之间那层东西。

打个比方:

Model = CPU,原始算力。

RAM = context window。

OS = harness。

Apps = agent的skills。

CPU能干啥,取决于操作系统。

模型能干啥,取决于harness。

Phase 0的project:写一份两页的文档,用自己的话定义:workflow vs agent、五个workflow patterns、四个context primitives、orchestrator-worker pattern。

如果不能脱稿写出来,说明还没理解到位。


Phase 1:从零构建第一个Agent(第3-5周)

写两遍agent。

第一遍,用原始的Anthropic SDK,大概100行Python。

第二遍,用Claude Agent SDK。

然后感受差异。

Build #1:裸循环

Agent loop一点都不神奇,就是这几步:

  1. 拿messages和tools调模型
  2. 解析出tool_use blocks
  3. 执行tool
  4. 把tool_result加回去
  5. 循环直到stop_reason = end_turn

自己写一遍,100行以内搞定。

一旦你写过这个,所有框架的代码你都能看懂了。

给它三个tool:web_search、read_file、write_file。

跑一个研究任务,把每一步的trace都读一遍。

Build #2:用Claude Agent SDK重写

Claude Agent SDK就是驱动Claude Code的那个harness。

加上这些:

CLAUDE.md,里面写项目规范。

一个Skill(一个文件夹,定义一个research-summary输出格式)。

一个PostToolUse hook,自动格式化agent写的每个文件。

一个通过Task工具生成的sub-agent。

然后写200字回答一个问题:「这次harness免费给了我什么,是我Build #1里自己写的?」

Phase 1的project:一个每日简报agent。读取你的Markdown笔记加RSS feeds,每天早上写一份摘要到磁盘。跑一周,看它怎么挂的,然后修复。

程序员在构建每日简报agent,读取markdown笔记和RSS feeds,输出摘要到磁盘的流程


Phase 2:构建有正确架构的真实Agent(第6-9周)

现在用LangGraph加Deep Agents来构建。

这是生产级stack。

LangGraph给你:状态机(nodes加edges)、PostgresSaver checkpointing(任意进程kill都能恢复)、时间旅行debugging(回到任意步骤)、human-in-the-loop interrupts、一手的LangSmith可观测性。

Deep Agents(LangChain打包的harness)给你:Planning middleware、虚拟文件系统、sub-agent生成、自动context compression、Skills。

核心概念:middleware。

Middleware是你定制一个打包好的agent而不用fork它的方式。

四个关键hook:

before_agent——loop开始前运行。

wrap_model_call——包装每个LLM调用。

before_tools——任何tool执行前运行。

after_tools——任何tool执行后运行。

Phase 2的project:研究分析师Agent。

输入一个研究问题。

架构:

Lead agent规划,写TODO list到虚拟文件系统。

并行生成3个搜索sub-agent(隔离context)。

Sub-agent写结果到文件,向父agent返回简短摘要。

Citation sub-agent验证claim。

Writer agent产出带inline citations的最终Markdown。

通过PostgresSaver持久化状态——kill进程后从断点恢复。

Human-in-the-loop interrupt:在token消耗超过1美元之前要求确认。

交付时附带一个LangSmith trace URL。


Phase 3:自己构建Harness层(第10-13周)

这是整个路线图里杠杆效应最高的阶段。

停止使用打包好的harness,自己写一个薄的。

不自己写过一次,你永远不会在生产环境里做出正确的harness取舍。

现代harness的10个组件:

  1. Loop control——驱动model→tools→model的while循环
  2. Tool dispatch——注册、schema验证、并行调用、重试
  3. Context management——system prompt组装、在window的85%处做compaction
  4. Persistence——每个node都checkpoint状态,支持resume、rewind、fork
  5. Sub-agent orchestration——隔离context的children、压缩摘要传回父agent
  6. Skills & progressive disclosure——只在相关时加载能力
  7. Hooks——PreToolUse、PostToolUse、PreCompact、Stop
  8. Observability——每个model调用、tool调用、sub-agent调用都有OTEL spans
  9. Sandboxing——代码在容器里执行,模型永远没有credentials
  10. Auth brokering——credentials永远不进模型的context

Phase 3的project:写一个mini-harness,大概1500行Python。

必须包括:

Tool registry来自@tool装饰器,带JSON-schema生成。

CLAUDE.md风格的system prompt loader。

SKILL.md渐进式披露loader。

Sub-agent生成原语,带隔离context。

Filesystem offload:任何超过20K tokens的tool result写到磁盘,context里替换成路径加10行preview。

在context window的85%处自动compaction。

可插拔hook系统(pre_tool、post_tool、stop)。

OpenTelemetry tracing。

Durable resume:每一步后持久化到SQLite,通过run ID重新加载。

真实交付物:1000字的后验分析,对比你的mini-harness和Claude Agent SDK及Deep Agents。你做对了什么,砍掉了什么,下次会怎么做不同。

程序员在撰写1000字后验分析报告,对比不同harness方案的优缺点


Phase 4:构建Eval和Regression Harness(第14-17周)

没有这个,所有「改进」都是感觉。

这是大多数工程师卡住的地方。

他们能构建一个很棒的agent,但无法判断下一次改动是让它变好了还是变差了。

四种你必须实现的eval类型:

1. Single-turn evals

给定输入,输出对不对。最便宜,尽量用确定性grader。持续跑。

2. Trajectory evals

Agent是否调用了正确的tool序列,参数是否正确。测试单步、全turn、多turn变体。

3. LLM-as-judge

开放式输出用这个:研究报告、code review、解释。每周用人工评级的样本校准。

4. End-state evals

有状态agent用:数据库写对了吗?正确的文件改了吗?把最终环境状态和ground truth对比。

一个不舒服的真相:

模型能检测到自己正在被评估。它们的表現会不同。

设计eval suite时要用真实的production queries,不要用合成数据。

Phase 4的project:给你的Phase 2 agent做regression harness。

Golden dataset:30到50个手工评级的研究问题(3个难度级别)。

事实类查询用确定性grader。

开放式用LLM-as-judge,五标准rubric。

Trajectory eval:agent是否做了规划、是否生成了2个以上sub-agent、是否引用了来源、是否在预算内完成。

AI agent在做规划决策,生成多个sub agent,引用来源,在预算内完成任务的评估流程可视化

接进GitHub Actions:golden set通过率下降3个点以上就block merge。

Production sampling:1%的线上trace做夜间自动评级。


Phase 5:生产环境加固(永久)

这个阶段永远不会结束。

五件永远重要的事:

1. 成本控制

缓存CLAUDE.md、system prompt、tool定义——能节省90%。

按难度路由:简单任务用Haiku,大多数任务用Sonnet,难的推理用Opus。

Batch API做非实时工作:有5折。

Multi-agent消耗的tokens大概是single-agent的15倍——只有在价值超过这个门槛时才用它。

2. 延迟

并行tool调用,永远——Anthropic自家研究agent的system prompt里明明白白写着「MUST use parallel tool calls」。

流式输出partial结果到UI。

Sub-agent扇出:一个60步的sequential agent可以优化成10步lead加5个并行10步sub-agent。

3. 安全和沙箱

所有代码执行都在沙箱里(Modal、E2B):永远不要在主进程里exec()模型输出。

Credentials在model context外面broker:模型永远看不到它用的API key。

任何不可逆操作都要human-in-the-loop interrupt。

4. 监控和漂移

告警项:每个请求的token成本、tool调用失败率、LLM-as-judge分数、p95延迟。

每次模型升级后重新校准evals——harness里编码了对模型能力的假设,这些假设会过时。

5. 弹性

任何运行超过60秒的agent都要用durable execution(Inngest、Temporal、PostgresSaver)。

每个node后checkpoint。

Rewind和fork永远要能实现。


五个生产级项目(选一个这周末就做)

按复杂度排序。

它们证明了你有公司真正需要的能力。

项目1:带SLM的AI移动应用

级别:入门 | 证明:Edge AI + 资源优化

用小语言模型构建离线优先移动应用。零API成本。完全隐私。

非trivial的地方:

按需lazy-load模型,内存压力时unload。

带语义分块的滑动context window。

老设备用4-bit quantization,新设备用8-bit。

Batch inference减少电池唤醒周期。

项目2:自我提升的编码Agent

级别:中级 | 证明:Agentic循环 + 生产环境调试

构建一个写代码、跑测试、从失败中学习的agent。不到代码可用不停。

非trivial的地方:

Plan→Execute→Test的反射循环,有最大迭代限制。

每个任务有隔离执行环境和资源限制。

Memory层级:短期(最近5次迭代)、长期(成功的patterns)、失败memory(错误签名加解决方案)。

执行前静态分析——检测危险操作。

项目3:视频编辑版的Cursor

级别:高级 | 证明:多模态AI + 复杂工具集成

Fork一个开源编辑器(Shotcut),构建一个理解剪辑意图的AI agent。

用户说「让这个有电影感」,agent处理剪辑、转场、色彩分级。

非trivial的地方:

Vision model分析每一帧,audio model分析对白。

意图翻译:「电影感」→具体参数(节奏、LUT、焦点模拟)。

通过帧差分析做场景检测。

增量预览——只重渲染受影响的部分。

项目4:个人生活OS Agent

级别:专家 | 证明:深度Context + 隐私优先架构

构建一个管理你的日历、财务、健康的agent。提前数月规划。通过分析睡眠模式和会议密度检测倦怠。

非trivial的地方:

实时摄取日历、财务、健康、通讯数据。

个人知识图谱,实体和关系。

每6小时运行一次的后台线程,检查异常。

价值对齐:用户声明优先级(家庭>工作)——每条建议都按优先级验证。

所有数据静态加密,密钥用户可控。

项目5:自主企业工作流Agent

级别:大师 | 证明:生产级编排

一个跑端到端业务工作流的agent。

监控Slack/Jira→规划执行→分发任务→汇报结果,附完整审计日志。

非trivial的地方:

事件驱动:监听Slack、Jira、email、监控系统。

多agent委派:orchestrator→communication agent、data agent、analysis agent、documentation agent。

自愈:指数退避、熔断器、自动重试决策。

不可变审计日志:每个操作、授权人、结果。

Human-in-the-loop:关键工作流执行前agent先提出计划。


技术栈

Framework:LangGraph 1.0 + Deep Agents。

为什么不选CrewAI、AutoGen、OpenAI Swarm?

CrewAI:demo最快,生产环境最脆。hackathon用用就行。

AutoGen:合并进了Microsoft Agent Framework。前途不明。

OpenAI Swarm:OpenAI自己在README里写了「not production-ready」。

LangGraph给你:状态机 + PostgresSaver持久化 + 时间旅行调试 + OTEL友好可观测性 + 模型无关。

LangGraph状态机可视化,Postgres持久化时间旅行调试,展示了复杂但可控的工作流

Harness参考:Claude Agent SDK。

学它,用它。它就是Claude Code用的那个harness。

CLAUDE.md + Skills + sub-agents + hooks + filesystem-as-memory。

2026年所有其他harness都在向这些原语收敛。

可观测性:选一个。

LangSmith:如果你用LangGraph。

Braintrust:如果你想要框架无关的CI gating(每月249刀flat)。

Arize Phoenix:如果你想要开源 + OTEL原生。

2026年跳过这些:

OpenAI Swarm——not production-ready(可以用Kimi Agent Swarm)。

OpenAI Assistants API——2026年中停用。

在没测量到实际recall问题之前不要自己搭向量库。

除非是临时用,否则跳过no-code agent平台。


一些benchmark数字

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才是。


说点真心话

大多数人会看完这篇文章,然后什么都不做。

收藏,说「好文」,回去继续做wrapper。

2026年的残酷真相:

可替代的:做薄薄的GPT wrapper。

不可替代的:交付带evals和durability的自主系统。

中间隔了5个项目和17周专注工作。

57%的团队现在生产环境里有agent。

其中89%接了可观测性。

质量是第一障碍(32%的团队提到了这一点)。

整个领域的瓶颈,是会做evals和harness的工程师。

不是会调LLM API的工程师。

这就是那个job opening。


这份路线图不会让你在17周内成为一个principal AI工程师。

但它会让你成为能构建和交付扛住生产流量的agent系统的人。

而这个能力,恰好是公司现在在付钱的。

下一步很简单:

挑一个项目。新手从项目1开始,已经在写代码的从项目5开始。开始就行。

这周末就开始构建。市场奖励交付,不奖励学习。

把一切都记录下来:你的架构决策、你的失败和恢复、你的自我修正循环。

公开发布。发布的时候@我,我会帮你传播。

到下个月,90%的人什么都不会做。他们还在做同样的wrapper。

另外10%的人会交付一些真实的东西。他们会有面试、有offer、有职业筹码。

选择很简单:

成为公司急需招聘的架构师,或者被时代淘汰。

专业能力是唯一的job security。生产系统是唯一重要的作品集。

现在,去构建能扛住现实的东西。


以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~

谢谢你看我的文章,我们,下次再见。

查看文章页 ↗