上周面试一个候选人。简历很漂亮——三年 LLM 应用开发，做过 RAG、做过 Function Calling、做过多轮对话系统。
我问他：「你平时自己写代码用什么工具？」
他说：「IntelliJ，偶尔用 Copilot 补全。」
我又问：「你上周的工作流是什么样的？从接到需求到交付。」
他想了想：「看需求文档，设计方案，写代码，联调，测试，上线。」
我说：「这个流程里，AI 在哪个环节？」
他愣了一下：「……写代码的时候用 Copilot。」
技术没问题。但他自己的工作流和五年前一模一样。
那一刻我就知道，他做不出好的 Agent 系统。 一个自己都不是 AI 驱动工作方式的人，设计不出 AI 驱动的产品。
传统分级标准正在失效
大多数公司评估 Agent 应用工程师，还在用传统后端的那套：算法题、系统设计、代码量、项目复杂度。
这套标准在 Agent 时代有一个致命盲区： 它考的是「写确定性代码」的能力，但 Agent 工程的核心难题是非确定性治理。
传统工程师写的是逻辑：输入 A，输出 B，永远如此。Agent 工程师设计的是行为边界：给定一个目标，Agent 自己决定怎么做，你负责确保它不跑偏。
这是两种完全不同的思维模式。我在 Agent 应用工程师——AI 时代增长最快的新岗位 里讲过，代码写完之后的所有事——权限、回滚、兜底、成本控制——才是真正难的。但这些能力在传统面试里完全考不出来。
更关键的是，我在 拟人化的数字员工 里提过一个判断： 功能（Bot）和角色（数字员工）的分界线，不在能力上限，在行为模式。 这个判断同样适用于工程师本身的分级——
P6 造功能，P7 造角色，P8 造组织。
六个维度，三级跃迁
我整理了一个 Agent 应用工程师的分级框架。六个维度，每个维度 P6、P7、P8 有质的区别：
| 维度 | P6（能交付） | P7（能设计） | P8（能定义） |
|---|---|---|---|
| Agent 交付 | 把一个 Agent 任务跑通 | 设计一个 Agent 岗位 | 定义 Agent 工程体系 |
| Prompt 工程 | 能写出稳定工作的 Prompt | 能设计 Prompt 架构（角色 / 边界 / 兜底 / 升级路径） | 能定义 Prompt 工程标准和评审体系 |
| 非确定性治理 | 知道 LLM 输出不稳定，会加 retry | 能设计 guardrails + 人机协作节点 + 降级策略 | 能定义「什么场景该用 Agent、什么不该」的判断框架 |
| 评估体系 | 靠人肉看输出对不对 | 能建 eval pipeline（case 集 + 自动评分 + 回归） | 能定义「什么叫 Agent 质量」的度量体系 |
| 系统集成 | 能对接 1-2 个 API / 工具 | 能设计多工具编排 + 状态管理 + 错误恢复 | 能设计跨系统 Agent 协作架构 |
| AI 原生行为 | 会用 AI 工具 | 自己的工作流已经 AI 驱动 | 定义团队的 AI 原生工作方式 |
前五个维度是「你能不能做好 Agent 工程」。第六个维度是元能力——你自己是不是 AI 原生地工作。
这个维度是一票否决级别的。后面单独说。
P6→P7：从执行到设计
P6 和 P7 的分界线，一句话： 你告诉他做什么，他能做出来（P6）；你告诉他一个岗位目标，他能设计出一个能胜任的 Agent（P7）。
类比：P6 是实习生（执行指令），P7 是正式员工（主动履职）。
具体差异在三个地方：
第一，Prompt 从「能跑」到「有架构」。
P6 写 Prompt 像写 SQL——把需求翻译成指令。P7 设计 Prompt 像设计系统——角色定义、能力边界、兜底策略、升级路径、多轮状态管理，是一个完整的架构。
第二，面对非确定性的态度完全不同。
P6 遇到 LLM 输出不稳定，第一反应是加 retry、加正则校验、加 if-else 兜底——本质上是 试图把非确定性系统约束成确定性的。
P7 知道非确定性是 Agent 的本质特征，不是 bug。他的设计思路是：哪些环节允许 Agent 自主判断，哪些环节必须人工确认，出错了怎么降级，怎么让 Agent 自己意识到「我不确定」。
我在 图灵完备的 Agent 里讲过，真正的 Agent 不是一次 Prompt → 一次 Response，而是有循环、有状态、有自主性的系统。P7 要能设计这种系统，而不是把它退化成带工具的 Chatbot。
第三，评估从「人肉看」到「建 pipeline」。
P6 验证 Agent 效果：跑几个 case，人眼看输出，觉得差不多就上线。
P7 会建一套 eval pipeline：标准 case 集、自动评分、回归测试、A/B 对比。因为他知道， 没有 eval 的 Agent 工程本质上是在靠运气做工程——你今天改了 Prompt，怎么知道没有把上周修好的 case 搞坏？
P7→P8：从设计到定义
P7 和 P8 的分界线： P7 能设计一个好的 Agent 系统，P8 能定义「什么是好的 Agent 系统」。
P8 做的事不再是具体的技术设计，而是三件更高层的事：
第一，定义判断框架。 什么场景该用 Agent、什么场景不该？什么任务适合自主执行、什么任务必须人工审批？这不是技术问题，是 风险判断 + 业务理解 + 组织设计 的综合。
第二，定义工程标准。 Prompt 怎么写算合格？eval 覆盖率多少算达标？Agent 上线前的 checklist 是什么？事故复盘怎么归类？P8 建立的是团队级的工程纪律。
第三，定义人机协作边界。 哪些决策留给人、哪些授权给 Agent、出事了谁负责。这是 Agent 时代独有的问题——传统软件没有「自主性」，所以也没有「授权边界」。
AI 原生行为：一票否决的第六维度
现在说最重要的。
如果候选人自己的工作流不是 AI 驱动的，他对 Agent 的理解一定停留在「API 调用」层面。
因为他没有体验过：
- AI 输出不稳定时，你作为用户的真实感受是什么——焦虑、不信任、想接管
- 什么时候该让 AI 自主、什么时候该加人工确认——这个分寸感不是设计出来的，是 用出来的
- 「主动性」的边界在哪里——太主动烦人、太被动没用——我在 拟人化的数字员工 里说的「主动性 + 判断力 + 边界感」三要素，只有自己天天用 AI 才有体感
类比：一个从不用自己产品的设计师，做不出好产品。一个自己不是 AI 原生工作方式的工程师，做不出好的 Agent 应用。
三个级别的具体差异：
| P6（会用） | P7（重构自己的工作流） | P8（定义团队的 AI 原生标准） | |
|---|---|---|---|
| 日常工具 | 遇到问题会问 AI，但工作流本身没变 | 调研用 Agent、代码用 Coding Agent 生成 + 审查、文档用 AI 起草 + 人改 | 定义团队工具链：什么环节必须 AI 先行、什么环节人必须兜底 |
| 思考方式 | 把 AI 当搜索引擎（问→答→复制） | 把 AI 当协作者（给上下文→迭代→判断）；新任务第一反应是「怎么拆给 AI」 | 能从组织层面判断哪些流程该被 AI 重构，重构后人做什么 |
| 最佳实践 | 知道几个 Prompt 技巧 | 有自己的 Prompt 库 / Skill 库 / 工作流模板，能说出「我为什么这样用」 | 建立团队的 AI 使用规范、评审标准、效果度量 |
| 自我度量 | 无意识 | 能感知「这件事 AI 帮我省了多少时间」，主动优化瓶颈环节 | 能度量团队 AI 渗透率，用数据证明 ROI |
反面信号：如果候选人说「我一般自己写，AI 写的质量不行」——这基本说明他还停留在 P6 的「把 AI 当搜索引擎」阶段。P7 的回答应该是「我让 AI 先出初稿，我改 20%」。
面试怎么考：问行为，不问知识
「你用不用 AI？」——所有人都会说用。要问 行为细节：
P6 验证：「你上周用 AI 做了什么？具体怎么用的？」
看是真用还是偶尔用。P6 的回答通常是「查了个 API 用法」「让它帮我写了个正则」——点状使用，没有融入工作流。
P7 验证：「你现在的工作流里，哪些环节已经离不开 AI 了？为什么？」
看是否重构了流程。P7 的回答应该是系统性的：「需求分析我会先让 AI 做竞品调研，代码我让 Coding Agent 生成初版然后我审查，测试用例也是 AI 生成的，我补边界 case。」
P8 验证：「如果你带一个 5 人团队，你怎么让他们的 AI 使用率从 20% 提到 80%？会遇到什么阻力？」
看组织思维。P8 应该能说出：阻力在哪（老工程师的路径依赖、质量担忧、考核机制不匹配）、怎么分阶段推、怎么度量效果。
还有一个杀手问题：「你最近一次因为 AI 改变了自己的工作习惯是什么？」
答不出来的，基本不是 AI 原生的。
我在 AI 时代的核心竞争力：提问能力 里讲过，区分 AI 人才最可靠的指标是提问质量。这里再补一个： 区分 Agent 工程师级别的，不是他会多少技术，而是他自己的工作方式有多 AI 原生。
一个反直觉的推论
传统后端强的人，不一定能做好 Agent 工程。
写惯了确定性代码的人，面对 LLM 的非确定性会本能地想「把它约束成确定性的」——过度结构化、过度 if-else、把 Agent 写成 workflow。
真正的 Agent 工程师要能接受： 设计行为边界，而不是设计执行路径。 你定义的是「这个角色在什么情况下应该做什么」，而不是「第一步做什么、第二步做什么」。
这个思维转变，只有在自己天天用 AI 工作时才会自然发生。因为你自己就是那个「非确定性系统」的用户——你每天都在体验「Agent 太主动了很烦」「Agent 太被动了没用」「Agent 做错了我想接管」的真实感受。
这些感受，就是你设计 Agent 行为边界时的直觉来源。
总结
Agent 应用工程师的分级，核心不是技术深度，而是三个跃迁：
- P6→P7：从「执行指令」到「设计角色」——你造的不是功能，是一个能胜任岗位的同事
- P7→P8：从「设计系统」到「定义标准」——你管的不是一个 Agent，是组织的 AI 工程纪律
- 贯穿所有级别的元能力：你自己是不是 AI 原生地工作
回到开头那个候选人。技术没问题，三年 LLM 经验也没问题。但他自己的工作流和五年前一模一样——AI 对他来说是一个偶尔用的工具，不是工作方式。
工具需要说明书。工作方式需要身体力行。
你没法招一个自己从不主动的人去设计「主动性」。你没法招一个自己不用 AI 的人去设计 AI 驱动的产品。
你的团队在招 Agent 工程师吗？你用什么标准判断 P6 和 P7？欢迎留言聊聊。