Anthropic FDE（前沿部署工程师）面试指南：Anthropic 为什么重金招聘一批“驻场工程师”？
这不是在招聘一个会写提示词的工程师，而是在寻找能把模型能力、客户流程和安全边界一起送进生产系统的人。
- Anthropic 当前美国 FDE 岗位年薪为 28 万至 32 万美元，买的不是提示词技巧，而是把 Claude 送进客户生产系统的能力。
- FDE 的完整闭环是发现工作流、划定风险边界、构建、评测、上线，再把现场模式反馈给产品。
- 面试真正筛的是五种能力能否合在一起：生产代码、Agent 架构判断、评测证据、客户管理和安全工程。
Anthropic 正在招聘一批有些反常的工程师。
他们不只在模型公司内部写代码，还要进入客户的系统，和银行、医疗机构、政府部门及大型企业的团队一起工作。Anthropic 当前美国 FDE 岗位列出的年薪是 28 万至 32 万美元，另有股权。
一家拥有前沿模型的公司，为什么还要花这么高的价格，招聘一批深入客户现场的人？
这份 FDE 面试指南表面上在告诉候选人如何准备招聘流程，真正透露的却是一项更重要的变化：当模型能力越来越强，AI 落地最稀缺的已经不是“会调用模型的人”，而是能把客户混乱的工作流程改造成可评估、可控制、可上线系统的人。
Anthropic 花高价购买的不是提示词技巧，而是把模型能力送过最后一公里的能力。
FDE 到底是什么？
FDE 是 Forward Deployed Engineer，通常译作前沿部署工程师或前线部署工程师。
这个职位最早因 Palantir 出名。它不是传统驻场外包，也不是只画架构图、做演示的售前岗位。FDE 要直接进入客户环境，把一个模糊的业务愿望变成能够运行的生产系统。
Anthropic 把 FDE 放在 Applied AI 团队。官方职责包括在客户系统中构建 Claude 生产应用，交付 MCP servers、sub-agents 和 agent skills，提供企业部署支持，并把反复出现的现场模式反馈给 Product 与 Engineering。
把这个岗位放到当前招聘信息里看，轮廓更清楚：
- 岗位职责与资格要求：需要生产 LLM 应用经验、扎实的 Python、客户沟通与发现能力、高自主性，以及在企业环境里交付系统的经验；
- 主要交付物：Claude 应用、MCP servers、sub-agents、Agent Skills，以及可以跨客户复用的部署模式；
- 当前美国年薪：28 万—32 万美元，另有股权；
- 工作方式：预计约 25% 的客户现场出差，至少 25% 的时间在办公室；
- 面试中的 AI 使用：可以用 Claude 准备，但现场面试默认由本人独立完成；assessment 除非明确允许，也不能交给 AI 代写。
这些工作不是互不相干的任务，而是一条首尾相接的路径。
最后一步决定了 FDE 不是普通外包。咨询项目结束后，经验可能只留在报告里；定制开发结束后，代码可能只服务一个客户。FDE 还要继续问：这次解决的问题，能不能变成下一百个客户都能使用的 MCP、Skill、评测套件或产品功能？
FDE 因而也是 Anthropic 的外部产品研发机制。
如果想继续理解企业为什么“用了同一个模型，结果却完全不同”，可以从部署条件而不是模型参数继续往下看。
继续阅读同样一个 AI 模型，为什么有的公司用出复利，有的公司用了个寂寞四条落地原则打底，配 L'Oréal、Lyft、Rakuten 三家实测数据佐证
为什么一家模型公司需要 FDE？
因为“模型很强”和“企业真的能用”之间，隔着一条很宽的鸿沟。
假设一家银行找到 Anthropic，说：“我们想做一个合规 Agent。”这句话听上去目标明确，实际上几乎没有可执行信息。FDE 必须继续追问：
- 到底是哪一个合规流程？
- 使用者是调查员、审核员，还是客户经理？
- 系统只是检索、摘要和起草，还是可以修改记录、发送消息甚至冻结账户？
- 哪些系统保存权威数据，数据是否完整、及时、可信？
- 用户权限如何传递给 Claude 调用的工具？
- 模型答错一次的实际代价是什么？
- 哪些动作必须由人审批？
- 上线成功看节省时间、召回率、误报率，还是案件完成率？
真正困难的不是写一句“你是一名资深合规专家”，而是把这些问题落实为身份权限、工具接口、数据过滤、审计记录、评测任务、人工审批和回滚机制。
这也是 Context Engineering 与普通 Prompt Engineering 的差别。Anthropic 对它的定义不只包含提示词，还包括系统指令、工具、MCP、外部数据、消息历史和不断变化的 Agent 状态。模型负责推理，不代表模型应该负责认证、权限过滤、重试、数据校验和高风险动作审批。
评测同样不能只看最后一段回答是否顺眼。Agent 声称“案件已经更新”，真正要检查的是后台记录是否改变、权限是否正确、审计轨迹是否完整。Anthropic 的 Agent eval 框架把完整轨迹与最终环境状态分开，正是因为一句成功声明不等于任务真的完成。
所以 FDE 的工作不是把 Claude 接进企业，而是决定 Claude 在什么边界内、凭什么证据、以什么方式进入企业。
它和几个相近岗位有什么不同？
FDE 容易被误认成软件工程师、Solutions Architect、AI 应用工程师或咨询顾问。它确实吸收了这些岗位的一部分，但主要产出和失败方式不同。
最关键的差别不只是“既懂技术又懂客户”。FDE 还是产品侦察兵。
他站在模型能力与客户现实发生碰撞的地方。哪些工具不好用，哪些权限模型缺失，哪些 Agent 行为难以评估，哪些需求在不同客户那里反复出现，他往往比内部产品经理更早看到。
高级 FDE 与普通项目交付者的分界也在这里。前者会把一次部署提炼成可复用模式；后者可能成功完成一个项目，却让下一位工程师从头再来。
面试真正想筛什么？
Anthropic 没有公布一套适用于所有 FDE 团队的固定流程。Applied AI、Custom Agents、Federal、Life Sciences 等团队面对的客户和案例不同，轮次、顺序和题目也可能变化。但原指南覆盖的准备范围很完整，可以整理成下面这张地图：
| 可能环节 | 主要考察 | 准备重点 |
|---|---|---|
| 简历与申请 | 是否做过生产 AI 和客户交付 | 写清部署了什么、服务谁、结果如何、你亲自负责什么 |
| Recruiter screen | 动机、岗位理解、级别与团队匹配 | Why Anthropic、Why FDE、最强客户部署故事 |
| Technical / Coding | 能否写出可信的生产代码 | Python、API、JSON、认证、重试、权限、测试、eval 脚本 |
| Applied AI / Claude Build | 能否构建真正有用的 Claude 系统 | Context Engineering、工具、MCP、Skills、sub-agents、失败恢复 |
| Enterprise System Design | 能否把原型做成生产系统 | 数据、IAM、审计、延迟、成本、评测、监控、回滚 |
| Customer Discovery | 能否把“想要 AI”收缩成可交付问题 | 用户、流程、风险、动作权限、成功指标、试点范围 |
| Values / Mission / Safety | 能否负责任地代表 Anthropic | 准备真实取舍，不背价值观口号 |
| Behavioral / Cross-functional | 所有权、低自我、冲突处理与成熟度 | 客户冲突、技术取舍、失败复盘、跨团队推进 |
| Final / Team Match | 是否适合目标客户和工作方式 | 反问客户类型、支持模式、产品反馈和安全审查 |
这些环节表面上各考一部分，最终都在回答同一个问题：
给你一个模糊、敏感、跨系统的企业任务，你能不能在没有完整剧本的情况下，把它变成一个客户敢用的 AI 产品？
1. 你能不能真的写代码
FDE 不是只负责开会、做需求和画架构图。Anthropic 的官方职位要求写得很明确：候选人需要熟练使用 Python，最好还掌握 TypeScript、Java 等语言，并且有交付生产应用的经验。
这轮不应只按 LeetCode 准备。原指南给出的高频题型更接近真实交付：
| 题型 | 可能任务 | 真正考察 |
|---|---|---|
| API 集成 | 拉取分页 CRM 数据，处理限流、超时和异常记录 | API 基础、错误处理、数据校验 |
| MCP / 工具 | 实现带 metadata filter 的文档搜索工具 | schema、最小数据返回、工具边界 |
| Eval 脚本 | 计算分类通过率并列出失败样本 | 指标设计、切片与可复现性 |
| Trace 分析 | 找出失败调用、缺失引用和重复循环 | 调试纪律、状态与工具调用理解 |
| 权限过滤 | 根据用户身份和 ACL 返回可访问文档 | 安全意识、防御性校验 |
| 可靠性 | 为不稳定 API 加指数退避、超时和结构化错误 | 重试策略、幂等与失败语义 |
| 结构化输出 | 校验模型 JSON 并返回可执行错误 | schema、边界数据、可恢复性 |
| 工作流图 | 检查工具依赖中的循环和非法状态转换 | 图结构、状态机与系统判断 |
所谓生产能力，不只是实现正常流程。它包括 API、认证、权限、分页、超时、重试、幂等、日志、测试、secrets 管理和异常数据处理。面试官还会观察你是否主动询问输入规模、脏数据、失败后的行为，以及凭什么判定任务成功。
一套稳妥的现场答题顺序是：
- 用自己的话重述任务，确认你没有理解错；
- 询问输入格式、数据规模、认证方式、延迟和异常情况；
- 先定义成功、失败、重试和升级分别返回什么；
- 实现最简单且安全的版本，不提前堆架构；
- 补正常、边界、无权限、重复数据和工具失败测试；
- 说明生产强化方案：日志、观测、secrets、限流、幂等与审计；
- 把这段代码放回客户工作流，解释它和上下游系统怎样连接。
一个普通回答可能是：“我会给企业文档做一个 RAG，再让 Claude 调用搜索工具。”接近 FDE 的回答还要处理：谁执行文档权限过滤？工具失败后如何恢复？哪些数据没有必要进入模型上下文？写操作如何防止重复执行？怎样确认 Agent 声称完成的动作真的改变了后台状态？
比如让你实现一个文档搜索工具，强回答不会马上开写，而会先确认权限由上游还是工具内部执行。即使上游已经过滤，也可以在工具层再次校验 ACL；返回结果只包含模型完成任务需要的字段；测试覆盖空结果、无权限文档、损坏 metadata 和重复 ID。这个过程比“我用了向量数据库”更能证明生产判断。
面试官不是只看代码能不能跑，而是看客户能不能信任这段代码。
2. 你能不能设计 Agent，而不迷信 Agent
成熟候选人不会听到需求后立刻宣布：“我们做一个多 Agent 系统。”
他会先判断，这个任务是否真的需要自主循环；普通工作流加一次模型调用是否已经足够；哪些环节必须由确定性代码负责；哪些判断适合交给 Claude；哪些动作必须由人确认。
这一轮可能让你设计企业客服助手、CRM MCP server、尽调 sub-agents、受监管报告 Skill，或者让你诊断一个在两个工具之间反复循环、不断读取旧数据的 Agent。
| 题型 | 例题方向 | 回答必须覆盖 |
|---|---|---|
| Claude 工作流 | 帮客服人员调用内部工具并生成带引用的回复 | 用户任务、上下文、工具、引用、eval、升级 |
| MCP 集成 | 安全读取 CRM，只允许更新批准字段 | 身份、字段级权限、schema、审计、幂等 |
| Sub-agent | 把尽调流程拆给多个专业 Agent | 是否真需拆分、上下文隔离、汇总与失败恢复 |
| Agent Skill | 为受监管报告制作可复用 Skill | 指令、领域资料、示例、辅助代码、版本与评测 |
| Trace 调试 | Agent 在两个工具间循环并读取旧数据 | 状态、终止条件、缓存、工具描述和观测 |
| Context Engineering | 数据越加越多，长上下文反而不稳定 | 选择、压缩、外部记忆、工具取数与更新策略 |
| 隐私与安全 | 避免敏感客户数据无必要进入模型上下文 | 最小数据、脱敏、权限、沙箱、人工批准 |
需要准备的知识也不是一串产品名，而是这些组件各自在什么条件下成立：
| 必须掌握 | 应当掌握 | 能拉开差距 |
|---|---|---|
| Claude API、工具调用、Prompt、Python 集成、eval、延迟与成本 | 结构化输出、Context Engineering、MCP、Agent Skills、sub-agents、人工审核 | trace 调试、隐私保护的工具流、MCP 代码执行、风险分级上线、跨客户复用模式 |
“我会优化提示词”已经不是充分答案。候选人必须能讨论上下文选择、工具 schema、结构化输出、身份与权限、状态管理、沙箱、日志、失败恢复和系统复杂度。
遇到完整系统设计题，可以沿着十步框架推进：
- 澄清工作流：谁在什么频率下完成什么任务，失败代价是什么；
- 定义成功指标：正确率、完成率、节省时间、升级率、采用率和安全指标；
- 画出数据与系统：文档、数据库、CRM、API、IAM、所有者和数据新鲜度；
- 划定动作边界：只读、起草、建议、写入和自动执行分别到哪一步；
- 选择架构：Claude、检索、工具、MCP、Skills、sub-agents 与确定性代码如何分工；
- 加入安全控制：认证、最小权限、secrets、PII、数据流与审计；
- 设计 eval：golden tasks、边界样本、trace review、outcome grader 和回归集；
- 设计观测：工具失败、循环、延迟、成本、用户反馈和生产状态；
- 制定上线计划：试点用户、人工审核、通过门槛、扩张条件与回滚；
- 形成产品回路：哪些能力可复用，哪些平台缺口要反馈给 Product 与 Engineering。
一个强答案通常会明确说：认证、权限过滤、重试和数据校验交给确定性代码；Claude 负责需要语义理解与推理的部分；工具只暴露窄接口；高风险写操作要求人工批准。先用一个工作流做试点，查看真实 trace 和 outcome，再决定是否增加 Agent 自主性。
很多时候，最好的 Agent 设计恰恰是删掉不必要的 Agent。
3. 你能不能把“效果不错”变成证据
Agent 最后输出“任务已经完成”，不代表任务真的完成。正确的验证对象可能是数据库中是否出现记录、文件是否正确生成、工单是否进入目标状态，或者用户权限是否真的得到执行。
Anthropic 对 Agent eval 的官方解释区分 task、trial、grader、trace 和 outcome。能力评测回答“系统现在能做到什么”，回归评测回答“它是否还能稳定完成过去已经会做的事”。
| 评测对象 | 应该检查什么 | 常见误区 |
|---|---|---|
| Task | 是否来自真实用户工作流，是否写清成功条件 | 用几个漂亮问题代替任务分布 |
| Trial | 同一任务多次运行是否稳定 | 一次成功就宣布能力成立 |
| Grader | 规则、状态检查、人工或模型评分是否适合目标 | 所有结果都交给语言模型主观打分 |
| Trace | 工具选择、参数、循环、引用和中间状态是否合理 | 只看最终文本，不看失败路径 |
| Outcome | 数据库、文件、工单和权限状态是否真的正确 | Agent 说“完成”就算完成 |
| Regression | 修改模型、工具或上下文后旧能力是否退化 | 只测新功能，不保留历史失败集 |
面试中如果被要求为客服 Agent、合规助手或报告生成系统设计评测，可以按六步回答：
- 从真实工作流定义 task，不从“回答看起来不错”开始；
- 用历史案例建立 golden set，再加入缺失数据、冲突来源、无权限和工具失败等边界样本；
- 为不同目标选择 grader：规则校验、状态检查、人工评分或模型评分；
- 同一任务运行多次，区分偶然成功和稳定能力；
- 同时检查 trace 与 outcome：它如何完成，以及后台结果是否真的正确；
- 把失败按类型切片，形成回归集和上线门槛。
指标必须跟任务变化。客服场景可以看解决正确率、引用质量、升级准确率、工具成功率、延迟和用户采用；合规场景还要看证据完整性、政策引用、误升级风险、幻觉事实和审计完整性。高风险写操作不能只靠语言 grader，应该直接检查数据库、文件、工单或权限状态。
所以候选人不能只展示几个成功截图。他必须能回答：系统在哪些真实任务上成功？同一任务重复运行是否稳定？哪类失败最常见？修改模型、工具或上下文策略后有没有退化？最终业务状态是否真的正确？上线阈值由谁决定，没通过时系统如何降级或回滚？
没有 eval，“效果很好”通常只是演示者的感觉。
4. 你能不能管理客户，而不只是服从客户
这项能力从 recruiter screen 就开始被判断。你至少要准备五类问题：为什么 Anthropic、为什么 FDE 而不是 SWE 或 Solutions Architect、最成熟的生产 AI 系统、最难的客户部署，以及你如何理解安全 AI 落地。
弱回答是“我做过 Claude 聊天机器人”“我有客户经验”“我会 Prompt Engineering”。强回答会说清完整链条：客户原本要解决什么工作流，你如何发现真实瓶颈，亲手构建了哪些集成，怎样处理权限与风险，用什么 eval 判断能否上线，最后产生了什么结果或产品反馈。
客户说“我们要在 30 天内向全公司上线自主 Agent”，并不意味着 FDE 的工作是点头，然后拼命赶工。
高水平候选人会先完成八组发现问题：
| 发现维度 | 必须问的问题 | 为什么 |
|---|---|---|
| 工作流 | 谁是实际用户？他今天完成什么任务或决定？ | 避免做出惊艳但无关的 Agent |
| 痛点 | 哪里最慢、最贵、最危险或最容易出错？ | 找到真正有价值的切入口 |
| 数据 | 权威来源在哪里？是否完整、及时、可信？ | 决定方案是否可行以及怎样取数 |
| 权限 | 谁能访问什么？哪些数据敏感？ | 决定身份传递和过滤位置 |
| 动作边界 | 系统只能读、起草和建议，还是可以写入执行？ | 决定自动化程度和审批机制 |
| 风险 | Claude 错一次会造成什么实际后果？ | 决定 eval 强度和人工审核 |
| 成功 | 什么指标能证明试点有效？ | 防止试点无限漂移或只看 Demo |
| 上线 | 第一批用户是谁？达到什么门槛才能扩大？ | 把原型变成采用路径 |
然后把目标收缩为一个具体工作流、一组真实用户、一套有限权限、一批历史测试任务，以及明确的上线门槛。第一版可能只允许读取和起草，不允许自动执行；高风险动作必须人工审批；只有当正确率、工具成功率、风险指标和用户采用达到约定标准后，系统才扩大范围。
行为面试也要沿着同一条链准备。普通 STAR 还不够，最好增加最后一个 Learning：
| 故事部分 | 必须包含 |
|---|---|
| Situation | 客户、工作流、技术系统，以及可靠性或安全 stakes |
| Task | 你负责发现、架构、代码、集成、评测、上线还是协调 |
| Action | 你本人具体构建、澄清、修改、拒绝或推动了什么 |
| Result | 采用、时间、准确率、风险、评测或产品反馈如何变化 |
| Learning | 这次经历怎样改变你后续的技术或客户工作方法 |
至少准备覆盖端到端所有权、模糊需求、架构改动、客户冲突、安全取舍、失败、产品反馈、跨部门协作和快速学习的故事。不要准备十个互不相关的小故事；更有效的是准备三到五个信息密度高的案例，并能从不同角度讲。
级别也不是靠 title 讲出来的：
| 目标范围 | 需要拿出的证据 | 常见失分 |
|---|---|---|
| Core FDE | 独立完成一个客户工作流，从发现做到试点上线 | 原型不错，生产强化与客户判断薄弱 |
| Senior / Founding FDE | 把单次成功变成跨客户可复用的 MCP、eval 模板或部署 playbook | 交付过项目，却没有沉淀模式 |
| Regulated / Custom Agents | 安全、隐私、审计、合规、人工审核与高风险工作流经验 | 夸大自动化，忽略监管与动作风险 |
| Applied AI Lead | 团队标准、人才培养、分行业方法与产品路线影响 | 个人很强，但不能通过团队放大 |
FDE 的价值不在于照单全收，而在于发现客户真正的问题，并阻止一个错误方案以更快速度上线。
5. 你能不能让安全进入架构
对 Anthropic 来说，“我认同 AI 安全”不是有效答案。
真正的安全判断要落到最小权限、敏感数据边界、工具调用范围、高风险动作审批、审计记录、上线评测、生产监控、异常升级和回滚机制。
一个医疗 Agent 如果只是帮医生整理文献，和一个可以直接修改患者用药记录的 Agent，不能使用同一套上线标准。能力相同，动作权限不同，风险等级就完全不同。
FDE 需要明确系统可以读什么、可以判断什么、可以写什么，以及在哪一步必须停下来交给人。这才叫安全工程。
这轮常见问题可以分成五类：
| 题型 | 可能问题 | 强回答信号 |
|---|---|---|
| Why Anthropic | 为什么想代表 Anthropic 进入客户现场？ | 把使命、岗位和自己的技术经历连在一起 |
| 安全权衡 | 什么条件会让你反对全自动方案？ | 能指出数据、动作、受影响者和证据缺口 |
| 使命冲突 | 是否曾为了安全选择更慢或收益更低的路径？ | 有真实代价，不把安全讲成零成本口号 |
| 不完整证据 | 证据不足时怎样判断“足够安全”？ | 分级风险、限制权限、试点、监控与升级 |
| 低自我 | 客户或同事证明你错了之后如何修正？ | 承认错误、修复系统、更新方法而非辩解 |
回答时不要表演使命认同。先承认业务价值，再把风险具体化：系统接触什么数据、能执行什么动作、失败影响谁、已有 eval 能证明什么、哪里需要人工审批、怎样监控退化。最后给出可执行选择：缩小范围、改为只读或起草、增加审批、延迟上线，或者在证据足够后逐步放权。
如果有四周，准备顺序可以这样排：
| 时间 | 技术实操 | Applied AI、客户与故事 |
|---|---|---|
| 第 1 周 | Python、TypeScript、API、async、JSON、测试、认证、重试 | 阅读工具、MCP、Skills、sub-agents、eval、Context Engineering；写 Why Anthropic 与 Why FDE |
| 第 2 周 | 做 API connector、MCP server、eval script、trace parser | 练金融、医疗、政府、客服发现案例；准备冲突、失败和安全故事 |
| 第 3 周 | 限时做生产型编码题，补测试与异常处理 | 设计含权限、观测、上线和产品反馈的完整 Claude 部署 |
| 第 4 周 | 模拟 coding、build、design、discovery、behavioral | 打磨完整 case study；确认团队、级别、出差、题型和 AI 规则 |
最值得做的备考作品不是聊天机器人，而是一个小型生产工作流。 选择客服分诊、销售研究、合规审核、文档问答或代码现代化中的一个场景，至少交付：Claude 集成、一到两个窄工具、清楚的权限边界、结构化输出、golden 与 edge eval、trace 日志、延迟和错误记录、安全假设、试点指标、上线门槛、回滚方案，以及哪些发现值得沉淀成可复用产品能力。
最后，在进入正式流程前向 recruiter 问清楚：
| 要确认什么 | 为什么会改变准备方式 |
|---|---|
| 目标团队是哪一种 FDE | Applied AI、Federal、Life Sciences 等案例完全不同 |
| 是否有现场 coding、在线评测或 take-home | 决定编码练习的形式与时间分配 |
| 是否使用 Claude、MCP、tools 或 Skills | 决定 Applied AI 需要准备到多具体 |
| 设计题偏客户架构还是内部 Agent 系统 | 两种题的入口、范围和深度不同 |
| 客户行业与出差比例 | 决定监管、现场协作和工作方式是否匹配 |
| 目标级别 | 决定故事要证明单次交付、复用模式还是团队杠杆 |
| 每种 assessment 的 AI 规则 | 避免把准备阶段允许使用 AI 误套到正式考核 |
原指南列出的最大失败原因，是候选人只证明了自己在一个维度很强：
| 候选人类型 | 典型断口 | 需要补什么 |
|---|---|---|
| 强 SWE | 代码好，客户发现和部署判断弱 | 工作流、采用、风险与上线故事 |
| Solutions Architect | 表达和架构好，缺少亲手构建 | 代码、工具、集成与生产结果 |
| Prompt Engineer | Prompt 好，生产系统薄弱 | 权限、eval、trace、可靠性与安全 |
| AI Researcher | 理论强，企业落地和协作弱 | 真实用户、系统约束与推广路径 |
| Consultant | 客户沟通强，Claude 技术深度不足 | API、MCP、Agent、eval 和调试实物 |
| Startup Founder | 自主性高，但可能跳过企业流程 | 安全审查、证据门槛、审计与复用模式 |
FDE 面试要找的是这些能力能否在同一个人身上闭合。
这件事更大的意义
Anthropic 设置 FDE，不只是新增了一个高薪岗位。它说明前沿模型公司的竞争正在从“谁的模型能力更强”，延伸到“谁能让模型进入最复杂、最昂贵、最敏感的真实工作流”。
模型能力越来越容易获得，客户环境却不会因此变得整齐：
- 每家公司都有不同的身份和权限系统；
- 企业数据普遍残缺、重复、过期或互相冲突；
- 实际流程和管理层想象的流程经常不是一回事；
- 安全、法务、IT、采购和业务部门的目标彼此冲突；
- Agent 的失败往往发生在多个工具和多轮状态之间；
- 一个成功 Demo 离组织真正采用还有很远。
FDE 的稀缺性来自一种很难标准化的能力：既能深入代码，又能理解组织；既能推动上线，又敢限制自动化；既解决一个客户的问题，又不把公司拖进无底洞式定制开发。
它还承担模型公司的现场学习功能。如果不同客户反复要求相同的权限控制，平台可能缺少统一授权能力；如果多个 Agent 都在同一种工具调用上失败，工具设计可能存在问题；如果某类工作流始终无法建立可靠 eval，产品也许还没有资格承诺自动化。
这些信息从客户现场流回产品和工程团队，才可能变成下一代平台能力。FDE 不是站在产品交付链的末端，而是把交付现场重新接回产品起点的人。
这也是这份面试指南真正透露出的反直觉结论：
AI 越通用，最后一公里反而越需要高水平的人。
不是因为 Claude 不够聪明，而是因为企业现实无法被一个通用提示词自动整理干净。
FDE 就是站在这片混乱里，把模型能力变成可信结果的人。