从2024年开始，“AI Engineer”成了一个被频繁提起、却极度模糊的角色。
在这个 Title 之下，折叠了完全不同的技术世界观：
有的人，会写 Prompt、会调 Temperature，就成了 AI Engineer；
而有的人，能用 LangChain 跑通一个 Demo，也才算入了门。
但当你真正参与过复杂的线上系统，构建过真实的 Agent 工作流后，会发现一个有趣的现象：
很多 AI 项目的“烂尾”，并不是因为模型不够强，而是因为工程能力的层级不够高。
那么, AI Engineer 都有哪些典型的段位层级划分，如何判断自己或者自己的产品目前在哪个阶段呢？
为了讲清楚这件事，我们来做一个思想实验。
假设你现在接到了一个需求：开发一款“旅游助手”。
随着你工程能力的逐级跃迁，这款产品会经历 7 次“转世”。
每一次转世，都对应着完全不同的用户体验，也对应着你从“调包侠”到“系统架构师”的蜕变。
Level 1: The Chat Wrapper (对话者)
产品版本：TravelMate v1.0
核心技术：Prompt Engineering
这是你入门的第一周。你拿到了 OpenAI 的 API Key，兴奋地写下了一段精心设计的 System Prompt：“你是一个资深的导游，说话风趣幽默...”
-
用户体验：
用户：“我想去云南玩5天，帮我规划一下。”
AI：“没问题亲！第一天大理古城，第二天玉龙雪山...（洋洋洒洒生成了1000字攻略）”
用户：“看起来不错！那就定这个行程吧，顺便帮我把机票买了。”
AI：“抱歉，我无法连接外部系统，无法帮您预订。不过您可以去携程看看...”
-
工程师视角：你觉得自己赢了，因为你用 Prompt 让 AI 的语气听起来很像人。
-
现实打击：在用户眼里，这只是一个“网络资料的整理员”。它活在过去（模型训练数据的截止日期前），无法感知现实，没有行动能力。
Level 2: The Tool User (工具使用者)
产品版本：TravelMate v2.0
核心技术：Function Calling / RAG
你意识到 v1.0 只是个“陪聊”，解决不了问题。于是你决定给大脑装上“手”和“眼”，接入了高德地图和天气 API。
-
用户体验：
用户：“我想明天去玉龙雪山，能去吗？”
AI：“（调用天气工具...）检测到明天丽江有暴雨，雪山索道大概率关闭。建议您改期或改为室内行程。”
用户：“哇，这个有用！”
-
工程师视角：你掌握了 Function Calling。你让 LLM 输出 JSON，然后用 Python 代码去执行查询。
-
局限：依然是传统软件开发的套路。你需要手写大量的 if/else 代码去判断：你需要告诉模型你都有哪些tool, “如果下雨，就调 A 工具；如果天晴，就调 B 工具”，基于模型的返回的tool call 和 参数进行调用，而AI 在这里只是帮你提取参数的工具人，流程依然是你在处理。
Level 3: The Protocol Architect (生态连接者)
产品版本：TravelMate v3.0
核心技术：MCP (Model Context Protocol)
需求升级了。用户问：“看看我下周哪天有空去云南？”
你傻眼了：要读用户的 Google Calendar？要读他的邮件确认年假？未来还要读他的 Notion 笔记？难道每接一个服务都要手写一套鉴权和连接代码？你尝试用MCP 构建服务；
-
用户体验：
用户：“帮我规划行程，避开我的工作会议。”
AI：“检测到您下周二下午有全员大会（来源：日历 MCP），建议您周三上午出发。已为您草拟了向老板请假的邮件（来源：Gmail MCP）。”
-
工程师视角：你不再手搓具体的 API 连接器，而是引入了 MCP。你的应用变成了一个通用的 Client，可以即插即用地挂载各种数据源。
-
跃迁：你从“写死代码的集成者”变成了“搭建积木的架构师”。你不再关心“怎么解析邮件”，你只关心“怎么连接 邮件 MCP Server”。
Level 4: The Agent Builder (自主行动者)
产品版本：TravelMate v4.0
核心技术：ReAct / Planning
你不想再写死逻辑了，你想让 AI 像人一样“有智能，可以灵活处理”。你引入了 Agent 框架，给了它订票、搜索、发邮件的所有能力，当然也包括权限。
-
用户体验：
用户：“给我订去昆明的机票，最便宜的，然后订个附近的酒店。”
AI：“收到！开始思考... 正在搜索机票... 发现特价票... 正在搜索酒店... 发现酒店... 预订成功！”
用户（崩溃）：“等等！你订了凌晨 3 点的红眼航班，却订了距离机场 50 公里的酒店？而且我还没确认你就扣款了？！”
-
工程师视角：你理解了 ReAct Loop (循环) 的核心能力， 但是也体会它带来的失控。AI 为了达成“订完”这个目标，开始主动思考，行动， 但是为了达成目标，会穷尽所有方法“不择手段”, 缺乏边界感和全局性。
-
教训：没有约束的智能，就是灾难。 很多所谓的 Agent 项目，会由于智能的混乱，带来糟糕用户体验，造成用户流失；
Level 5: The Workflow/Graph Engineer (系统掌控者)
产品版本：TravelMate v5.0
核心技术：LangGraph / State Machine / Human-in-the-loop
痛定思痛，你决定收回部分控制权。你不再迷信“全自动”，而是设计了一套基于图论的严密工作流。
-
用户体验：
用户：“订机票和酒店。”
AI：“已为您锁定周三上午 10 点的航班（状态：待支付）。基于航班时间，推荐了 3 家接机方便的酒店。请您确认航班信息，我再进行下一步扣款。”
-
工程师视角：你使用了 LangGraph。你定义了节点（Node）和边（Edge）：
搜索航班 -> 等待确认 -> 搜索酒店 -> 检查预算 -> 支付。 -
跃迁：你不仅会写 Loop，更会设计流程。你知道哪里该让 AI 发挥，哪里必须设置断点（Breakpoint）让人类介入。这是从“Demo”走向“生产环境”的关键一步。
Level 6: The Cognitive Companion (有记忆的智能体)
产品版本：TravelMate v6.0
核心技术：Long-term Memory / Context Engineering
你的 SOP 跑得很顺，但用户依然觉得 AI 像个“最熟悉的陌生人”。 每次打开 App，都要重新说一遍“我不吃辣”、“我带着孩子”。你意识到，真正的智能体，不仅仅是拥有技能（Skill），更是拥有记忆（Memory）和自主上下文(Context)感知的能力。
-
用户体验：
用户：“我想去云南，帮我安排一下。”
AI：“Neal，记得上次去三亚你提过孩子坐车容易晕车（记忆提取），这次去云南我特意避开了盘山公路太多的景点。 另外，依然为您首选了带恒温泳池的酒店（偏好复用）。这是基于您习惯生成的‘亲子舒适游’方案。”
用户：“天哪，你居然都记得！这就不用我操心了。”
-
工程师视角：你不再只是在编排流程，你开始构建系统的记忆中枢。你利用向量数据库存储用户的长期记忆，设计了一套 User Profile 动态更新机制, 在面对用户请求时，可以动态获取对应的上下文进行背景补充；现在的 TravelMate 不再是一个冷冰冰的工具，而是一个“注入了用户偏好上下文”的专属伴侣。
-
跃迁：从“通用的工具”变成了“懂你的伙伴”。
Level 7: The System Architect (数据治理与进化)
产品版本：TravelMate v7.0
核心技术：LLMOps / Evals / Token Optimization
这是目前很多优秀产品的终极形态。你跳脱出了具体的产品功能开发，站在了上帝视角俯瞰整个系统。 你不再关心某个具体的 Prompt 写得好不好，你关心的是整个系统的智商边界、响应速度与运营成本。
-
用户体验：
用户：(并未察觉到具体功能变化，只觉得产品越来越“顺手”) 以前生成攻略要等 30 秒，现在只要 5 秒； 以前 AI 偶尔会把景点名字搞错，最近两个月一次都没错过； 即使在服务器高峰期，服务依然稳如泰山。
-
工程师视角： 你正在看着监控仪表盘：
- 成本调优：你发现 80% 的简单意图识别不需要用 GPT-5，于是引入了路由层，自动切换到更便宜的小模型，Token 成本降低了 60%。
- 自动化评估 (Evals)：你构建了一套自动化测试集。每次代码提交，系统会自动模拟 1000 个用户请求，评估回答的准确率和幻觉率。
- 数据飞轮：你将用户修正过的数据收集起来，用于微调（Fine-tune）私有模型。系统每天都在通过真实数据自我进化。
-
结论： 你不再是在写代码，你是在治理一个生态。你通过数据、算力和算法的精细化调配，让系统在稳健运行的同时，实现自我迭代与进化。
结语
从 v1.0 的“鹦鹉学舌”，到 v7.0 的“智能生态”。
每一个版本的迭代，都不是因为模型忽然变聪明了，而是因为你作为 AI Engineer，在架构设计、协议标准、交互逻辑、系统治理上的认知跃迁。
现在，请低头看看你手头的代码：
你是在通过 Prompt 试图“催眠”模型（Level 1），
还是在通过 Graph 和 SOP 构建一个可信赖的系统（Level 5+）？
这种差距，才是 AI 时代的真正护城河。
阅读更多 AI 工程化实验室系列文章 或关注公众号 AI工程化实验室，深入探索 RAG优化、Agent编排硬核技术干货。
