一个好的 AI Engineer到底创造了什么价值？

随着近年来各式各样 AI startups 的兴起，AI Engineer 作为一种新的职位，开始变得越来越普遍。很多人都有疑问：这个职位到底是做什么的？有些人会把 AI Engineer 和 LLM 的训练、inference 联系起来。有些在 2022 年 LLM 爆发之前就从事 CV、NLP 领域的人则会想：这和由来已久的 Machine Learning Engineer 到底是不是一回事？

这些疑惑都有道理。当一个新鲜事物逐渐发展起来的时候，本来就会存在很多模糊的地方。不同公司在使用一个热门 title 的时候，实际需要的人才也很可能并不一样。

我在大公司和startups都做过NLP方面的ML engineer，现在在一家B轮的startup工作。我最熟悉的是各种垂直领域的应用型初创公司。这些公司往往有大量 AI Engineer 的需求，而且对这个职位的定义相对比较一致。所以我想结合自己的经验，分享一下我对这个新生岗位的理解。

更具体地说，我想回答两个问题：
第一，AI Engineer 到底是做什么的？
以及更重要的，一个好的 AI Engineer，到底为公司创造什么独特的价值？

AI Engineer 不是什么，又和 MLE 有什么不同？

在讲 AI Engineer 是什么之前，我需要先讲一下它不是什么。

首先，一般业内所说的 AI Engineer 并不训练大语言模型。随着 foundation models 的泛化能力越来越强，同时训练模型的成本也不断攀升，LLM 训练这件事越来越向少数 Model Labs 集中。大部分应用层的 AI startups 不会、或者很少自己训练模型。在 Model Labs 里，负责模型训练的通常是 Research Scientists 和 Research Engineers。

另外，大多数 AI Engineer 的工作也和 inference 其实也搭不上太大关系。有些 infra startups 会需要专门的人来做 model inference，但这一部分工作非常偏 infra，和一般意义上的 AI Engineer 在工作性质和技能要求上都很不一样。

接下来我想花点时间谈谈最容易混淆也最有争议的一个问题：
AI Engineer 是不是就是传统 Machine Learning Engineer 的旧瓶装新酒？

直接给出我的看法：不是。

两三年前，这两个职位之间的关系可能还比较模糊，而且很多现在的 AI Engineer 也是从之前的 MLE 逐渐转变过来的。但随着这几年 agentic system 的发展，很多围绕 LLM 设计和构建系统、产品的思路与范式逐渐形成，已经开始沿着和经典 Machine Learning Engineering 不同的方向发展。

这有点像在一棵进化树上，一个物种逐渐分化成了两个物种。
当然，一些新的 AI startups 在招聘时可能仍然沿用 ML Engineer 的叫法，所以具体工作的性质还是要看公司的实际需求。这里我只是想做一个大致的区分。

传统的 Machine Learning Engineer 至少十多年前就已经存在，往往集中在 NLP、CV、自动驾驶、搜索、广告和推荐系统等领域。主要工作包括收集数据、清洗数据、协调数据标注、训练模型，以及部署模型。在 NLP 和 CV 领域，很多问题都有相对成熟的研究范式，比如 named entity detection、classification、image segmentation 等。

我在经典 ML 时代和 LLM 时代都做过 AI Assistant 产品，所以我觉得自己的经历还挺适合用来比较 MLE 和 AI Engineer 工作之间的区别。
在 2023 年 LLM 普及以前，已经有不少 startups 和大厂在做类似于今天 AI agents 的产品。只不过那时候还不叫 agents，一般叫 AI assistant。说到这里我突然想到，《乌合之众》的作者勒庞讲过，词语会在人们的脑海中唤起具体的形象和联想。可能是因为一提到 AI assistant，人们就会联想起 Siri 和 Alexa 一类的语音助手。不知道是哪位聪明的营销天才发明了 agentic 这个词，一下子和旧时代的 AI 产品划清了界限。

有点儿跑题了。

在前 LLM 时代，如果想做一个能够在网页或者 Slack 上帮人搜索信息、执行任务的 AI chatbot，是个相当浩大的工程，背后涉及一整套复杂的工程系统。

用户问了一个问题以后，系统可能先要判断用户使用的语言（language detection），然后做翻译（translation），抓取其中提到的人名、地名和组织（NER），识别用户意图（intent classification），最后再从可选的行动方案中找出最优解（search and ranking）。如果过程中还需要向用户提 follow-up questions，那通常还需要一个 state machine。其中的每一步，都可能需要一个甚至多个 machine learning models。这些模型往往已经相当成熟，大多是用现有的 BERT、RoBERTa 或类似的 classifier，在自己标注的数据集上重新训练。

一个 ML Engineer 的工作成效，往往就体现在自己负责的模型 performance 上。Evaluation 通常比较直接，因为已经有比较成熟的 metrics。大量时间会花在收集数据、标注数据和清洗数据上。

而且很多时候，随着 business 的变化，还需要不断重新设计和定义 taxonomy。比如，一个 AI assistant 原本只是为了帮助用户解决 IT 问题，现在公司扩展了新的业务，希望它也能支持 HR 相关的问题。如果你负责 intent classification，就需要在模型的 taxonomy 里加入 HR 相关的用户意图标签。比如原来的model可以分辨申请新软件安装，更换硬件设备，和重设密码这三种意图就够了，现在需要加入请假和报税。这意味着你要收集新数据、标注数据，然后重新训练模型。

到了 LLM 时代，AI agent 的系统设计范式发生了很大的变化。

站在模型和软件产品中间的 ML Engineers 感受到了 LLM 带来的强大冲击。过去那套精密的 NLP 系统虽然严谨，但也过于复杂和迟缓。我们开始意识到，需要围绕 LLM 强大的 reasoning 和泛化能力，重新设计一套更轻巧的系统，充分释放模型本身的能力。于是，人们开始主动放弃自己定义好的那套 pipeline，放弃人为规定每一个模型应该负责什么，把模型从流水线上的固定岗位里“解放”出来，让模型自己判断下一步应该做什么。

当不再有一条由自己负责的特定任务模型组成的 pipeline 时，这些人的工作也就逐渐和经典的 ML Engineer 告别了。

取而代之的是两个新的问题：

• 如何让 LLM 在真实环境中尽可能好地运作，并真正带来可见的经济价值？
• 如何衡量你的 agents 到底有没有在进步？

而这两个问题，也正好引出了我认为今天 AI Engineer 最核心的两个价值：harness engineering 和 evals。

一个好的 AI Engineer，到底创造什么价值？

如果把 LLM 比作蒸汽机，那么 harness engineering 就好比围绕蒸汽机设计和搭建一整套工程系统，让蒸汽机真正能够完成某类工作，并产生经济效益。就像后来人们围绕蒸汽机做出了纺织机、火车和轮船。模型本身再强，如果不能被放进一个真实、可靠、可控的工作系统里，也很难真正产生价值。
近几年，业界围绕 agent harness 的技术范式发展得很快。常见的 components 主要有下面这些：

• Tools
  给 LLM 工具，让它能够完成各种工作。
  以前人们会认为，要围绕具体场景设计非常特定的工具，agent 才能变得厉害。
  但最近这一年，大家逐渐意识到，很多时候反而是少即是多：最聪明的模型加上最简单的工具，往往效果最好。只要给 agent 一个 sandbox 环境，让它能够写代码，agent 就可以完成很多更重的任务，比如搜索信息、撰写一份符合律所格式要求的 PDF 法律文件，或者生成一份精美的 PPT。工具设计得越复杂，反而越容易出错。正所谓大巧不工。
• Memory
  这里的 memory，既包括一次 LLM call 里的 context，也包括 cross-session memory，或者 user preference 一类的长期 memory。随着现在 agent 能完成的高价值任务越来越复杂，long-horizon task 对 memory management 的要求也越来越高。
  Auto-compaction 成了处理 long-horizon 任务下 context overflow 问题的重要方法，subagent 和基于 filesystem 的 memory 也逐渐成为重要组件。
• Orchestration
  最早的 agent 大多是 chatbot 的形式。你给它一个问题或者一条指令，它去做一件事，然后把结果返回给你。但随着 AI agents 能完成的任务越来越多、能够持续运行的时间越来越长，人反而开始成为效率的瓶颈。于是有人会想：如果一件事情本身是有规律的，什么时候该做、多久做一次都有迹可循，那为什么还要等人去问？为什么不能让 agent 在该做的时候，自己把事情做好？于是就有了background agents，或者所谓的 auto-agent。

这些都是 AI Engineer 今天非常重要的工作。但如果说有一项工作最能体现 AI Engineer 的独特价值，我认为其实不是 harness，而是 evals。

我和很多非常优秀的同事聊天时，他们总是一再强调 evals 的价值。但据我观察，很多人其实还没有真正意识到这一点。
-baidu 1point3acres一个产品从 demo 走到几百、上千家客户使用，一家公司从 seed round 走到 Series C，往往都会经历一个非常常见的场景。产品做出来了，测试效果很好。Harness 用的是最先进的设计，什么 subagent、auto-compaction、coding、RAG、memory 全都放进去了，模型也直接用最好、最贵的。

但是上线一个月之后，客户开始大量发来 bug reports，各种 hallucination 和 quality 问题接踵而来。Founders 很着急，CTO 开始一个接一个地开 war room。大家一头雾水，只能一个问题一个问题地 debug。每个 hallucination 好像调一调 prompt 都能解决，但往往是按下葫芦浮起瓢，问题会越修越多。

这是因为 LLM 本身就具有统计意义上的不确定性，而 agent 的 non-determinism 又会在多步执行过程中不断 compound，成倍地放大。Agent 的输出往往无法像传统软件工程一样，简单通过 unit test 或者 integration test 来测试和发现问题。
于是，evals 就扛起了 Agent 质量保障的大旗。

Evals 主要有两个任务。

第一个，是构建自己领域的 benchmark，用来衡量 agent 长期 hill-climbing 的能力。

虽然现在有很多公开 benchmark，比如衡量 coding 能力的 Terminal-Bench，但真正最能评估自己领域 agent 能力的，往往还是自己的数据。这个 benchmark dataset 需要能够代表真实用户在你的领域里会做的工作，同时还要足够难，以至于你的 baseline 分数一开始可能很低。这需要对本领域有很深的理解，而且往往需要和真正的专业人士合作。

所有没有通过的 tasks，都像一座座灯塔，标志着 agent 目前能力的边界，同时也明确指出了下一步可以改进的方向。

每次对 harness 做出比较大的改动、升级 model，或者修改重要 prompt 之前，都应该先在这个 benchmark 上跑一遍，看看到底有没有实际提高。让 benchmark 来说话。没有带来提高的改动，就不要进 production。对系统的改进不应该靠拍脑袋决定，也不能仅仅因为某个工程方案听起来很酷炫。

第二个，是 regression test。

这需要一个足够多样的数据集，里面包含 agent 已经能够做好的任务。它和 benchmark 的目标不一样。

Benchmark 衡量的是 agent frontier capability 有没有向前推进，而 regression test 是为了确保每一次代码和 prompt 的改动，不会让 agent 在自己原本已经能做好的事情上出现倒退。这是 ship 新功能以及做 bug fix 之前的一道 guardrail。一个 agent 没有 regression dataset，就像传统软件没有 unit tests。你很可能修好了一个 bug，却同时制造了更多新的问题。

事实上，我认为一家应用型 AI 公司做 evals 的能力，在相当程度上决定了这家公司的技术护城河。

但即使有了 harness 和 evals，我觉得一个好的 AI Engineer 仍然不只是一个会搭系统、会写 benchmark 的工程师。真正稀缺的，还有判断力。

我现在所在的公司做 Legal AI，客户都是律师和 paralegals。刚来的时候，有一件事情让我非常不适应：任何涉及 Agent 的 troubleshooting 都很让人头大。用户看到的是 Agent hallucinate 了。但每一次 hallucination 背后的 root cause 可能都不一样，你需要一个一个去看 trace、理解整个执行过程。

慢慢看了几十个、上百个 traces 之后，才能逐渐看出一些门道，开始意识到一些看似毫不相关的 hallucination 案例之间，其实存在共同的底层逻辑。到了这个时候，你才有可能提出 harness 层面的改进，从系统上解决一整类问题，而不是只修一个 case。

大概一年前我刚进公司的时候，这件事让我非常头疼。因为用户的问题和 agent 的工作都涉及很深的法律知识。什么 deposition、statutes of limitations、UM 和 UIM 的区别，有时候光看懂用户到底在问什么就要花很久，更别说理解 agent 为什么出错了。

我刚进公司的时候问过另一个比我早来的 AI Engineer 同事。他开玩笑说，自己的 moat 就是已经看过几百个 agent traces，所以现在很快就能判断出 agent 大概出了什么问题。我后来越来越能理解这句话。因为你真正需要积累的，不只是某一种 debugging 技巧，而是对用户任务、domain knowledge、模型行为和系统 failure modes 的整体理解。

当然，时过境迁。现在有了 coding agents、各种 MCP 和 CLI，以及 skills 的帮助，系统性分析 traces 的工作已经可以由 coding agent 大规模完成。一个 coding agent 也许可以在分析 1000 个 traces 之后，帮你总结 failure patterns，再给你列出 20 条工程改进建议。

但人的判断力仍然至关重要。因为最后你还是需要告诉你的 CTO下个月到底最应该做什么？以及我们要如何衡量产品是不是真的在进步？

这也是我越来越觉得，一个好的 AI Engineer 真正创造的价值所在。不是用了多少最新的 agent framework，也不是往系统里堆了多少 memory、RAG、subagent 或者复杂的 orchestration。而是能不能把一个 probabilistic、non-deterministic 的智能系统，真正放进复杂的真实世界里，让它持续、可靠地创造经济价值。
能不能发现它能力的边界。
能不能理解它为什么失败。
能不能判断下一步最值得改进的是什么。
以及最重要的——能不能证明，它真的变得更好了。

AI Engineer 会走向哪里？

我看到的 AI Engineer 的未来，是这个角色本身也会越来越泛化。它不一定会永远停留在一个狭窄的“工程职位”里，而可能逐渐向技术、产品和 business 的交叉地带延伸。

我见过的最厉害的 AI Engineers，有非常不同的职业选择和发展路径。

有人选择继续深化技术，去了 big model labs 做模型训练，或者基于 evals，让 LLM 在 coding、搜索等特定任务上做得更好。

有的人逐渐成为了技术加产品负责人。因为 AI Engineer 最主要的工作之一，就是确保 agent 在最专业、最有挑战性的任务上的质量。同时，因为大量参与 evals、看 failure cases、理解真实用户任务，AI Engineer 往往也是公司里最懂 domain knowledge 的工程师群体之一。所以，对产品感兴趣的人，很有机会在 startups 里承担更多产品负责人的角色。

还有的人学而优则创业，这在旧金山硅谷很普遍。

某种程度上，这些发展方向其实都指向同一件事情。AI Engineer 的价值并不只在于“懂 AI”。而在于他能不能连接模型、工程、产品、用户和业务，并且把模型不断增长的能力真正转化成现实世界里的价值。

AI 行业的发展日新月异，所以我们还是要用发展的眼光去看行业和职业本身。今天我们所说的 AI Engineer，几年以后也许还会继续变化，甚至可能再次分化出新的职业。

这篇文章是我在当下这个时间点的一些思考和总结。如果它能给读到这里的你带来一点帮助，我就很高兴了。之前我还写过一篇AI startup面试心得，附在这里希望对正在面试的人有帮助。如果对这个话题感兴趣，欢迎来加我的领英一起交流。

Hmmm 作为专门做这个领域的人，表示写的非常好！很赞同。终于有一篇写到点子上的帖子了！

这就是一个全新范式的岗位，比如光是context engineering里memory的问题，就有很多可以做的。

llm之前的mle可以说还算是个相对独立的工种（当然和sde重合也很多），llm之后的ai engineer/mle其实就是新时代的backend engineer。看看周围有没有这种趋势：之前做纯backend的组是不是有越来越多开发自己的internal/external agent/llm workflow了，原本做nlp/small language model training的nlp/ml engineer是不是也开始做internal/external agent/llm workflow了。 所以当所有人都可以call llm endpoint来获得模型能力了之后，剩下的就是system design和eval了，大部分的engineer都可以做。

All Indians Engineer?

不必纠结职位的名称

匿名用户 发表于 2026-8-15 19:39
不必纠结职位的名称

是的，有些公司 software engineer 啥都做， 做data engineering，做ml活，做site reliability，做devops。

某公司的data engineer都叫 software engineer，估计是招sde做data engineer。
某公司的MLE叫software engineer，市场上就没那么多MLE，只能招sde 顶上。

好文！ 谢谢楼主！

AI Engineer一直没有一个清晰点的定义吧？

好帖！讲的非常系统和细致，经常有人问AI到底创造了什么新岗位，可以来好好读一读这一篇，而且这也是现在市场上需求比较大的职位

好文，特别认同“evals 是护城河”这个判断。补充一个 infra 视角：agent 从 demo 到生产，很多时候先撞墙的不是模型，而是数据访问——权限、时延、成本。agent 一旦要碰真实企业数据做 long-horizon 任务，分级存储、缓存、元数据检索这些工程问题会直接决定 harness 的上限。所以我觉得 harness engineering 还可以再拆一层：外层是 orchestration 和 memory，底层是数据基础设施。这层在 demo 里看不出差别，上了生产差距会指数级放大。

另外楼主说“未通过的 tasks 是灯塔”很妙。我们做系统可靠性也是类似逻辑：regression 用例都是从线上真实 failure 一条条攒出来的，攒的其实是 failure modes 数据集，和 agent evals 殊途同归。

一个价值判断是
Does 1 x AI_ENGINEER == 2xDATA_ENGINEER + 1x DATA_SCIENTIST + 1xBackend + 1xFrontEnd

如果
AI_ENGINEER == DATA_ENGINEER or DATA_SCIENTIST or FULL_STACK

那似乎没有效率的提升，新瓶旧酒