前沿部署工程师（Forward Deployed Engineer，简称FDE）正成为AI行业最热门的职位之一。今年5月，OpenAI宣布成立一家专门帮助企业部署AI的公司，并计划收购应用AI咨询公司Tomoro，后者约150名工程师和部署专家将加入。新公司获得超过40亿美元初始投资，麦肯锡、贝恩和凯捷均在参与者之列。这一消息公布后，国内的云计算、ERP和软件服务企业开始密集布局FDE模式，阿里、字节跳动、蚂蚁集团、Minimax、商汤等公司也相继挂出FDE岗位招聘信息。
FDE并非新概念。Palantir二十多年前便采用这一岗位设置，并将其视为一种产品开发方法。在Palantir的实践中，工程师深入客户现场理解需求、接入数据、修改系统，再将现场发现带回核心研发团队。Palantir官方文档将该过程形容为软件研发中的“人类反向传播”。近两年，随着Palantir估值上升，外界开始用FDE重新解释这家公司的增长，FDE能够解释的，是一家需要工程师深入客户现场的软件公司，为何仍能保有软件生意的高毛利率。
FDE的工作场景与咨询顾问、解决方案架构师和驻场开发有相似之处，但责任的终点不同。顾问通常交付建议，驻场工程师对约定范围内的上线和运维负责，FDE则要把模糊问题变成生产系统，再用采用率和业务指标判断系统是否有效。Palantir公布的食品企业General Mills案例展示了FDE的工作方式：双方接入200张主数据和运营数据表，建立供应链决策系统ELF，该系统每天检查约3000份订单，提供约400条调整建议，其中超过70％被工作人员接受。General Mills称，这套系统每天节省约4万美元。
国内企业对FDE的押注路径呈现差异化。明略科技在中期业绩中披露，公司已有约30％的交付人员转型为FDE，并将推动普联软件的FDE模式转型，试图将项目经验写成Skill和Agent，让下一次交付减少对人的依赖。软通动力提出“AI Factory+行业经验+FDE”模式，覆盖咨询、模型部署、智能体开发到持续运营全链条。致远互联则将FDE定义为深入现场完成数据治理和定制功能开发，再把业务痛点反馈给内部团队。金蝶也把FDE写进产品交付体系，2026年8月，阳光智维与金蝶启动统一智能平台项目，外部团队将进场整理审核规则、样本和知识，建立“AI初审、人工复核”的流程。
中远海控则选择培养自己的FDE队伍。公司表示，将以FDE人才培养为抓手，建设业务与技术结合的内部AI研发团队。对于拥有复杂航运网络的大企业，内部人员更清楚哪些数据口径不能混用、哪个审批环节不能绕开，也知道一个看似低效的流程为何一直保留。内外部FDE会合作，也会竞争。新模型和首批高风险场景需要外部经验；场景进入日常运营后，内部团队必须接管权限、评测和修改能力。
FDE越接近真实业务，权限矛盾越难回避。外部团队需要的是完成特定任务所需的最小信息：开发与生产环境隔离，敏感字段分级，账号按项目授权，代码合并由内部审批，操作留下日志，项目结束后回收权限。技术只能限制成员能看什么，无法回答企业为什么愿意让你看的问题。外部团队可能接触成本结构、客户关系和未公开的经营规则，保密协议无法完全消除知识外溢风险。反过来，如果企业只提供层层过滤的材料，FDE又容易停在演示阶段，做出一个看起来聪明、实际无法接管业务的应用。
FDE正在成为宽泛的商业标签，售前、实施和外包团队都可能改名为FDE。判断它是不是新模式，可以看三个问题：工程师是否写生产代码，是否对实际采用负责，单个客户的经验是否进入标准产品。缺少最后一项，再豪华的岗位名称也改变不了项目制生意。检验合作是否健康，可以看一个反常识指标：后续项目需要的外部人力是否减少。第一套系统需要十个人驻场，第二套仍从数据清洗重新做起，第三套还依赖同一批人救火，FDE就没有形成软件杠杆，只是按人天收费的项目生意。
外部FDE见过更多模型失败的方式，也更了解产品接下来可能获得什么能力，这种视角可以帮企业少做几个没有生产价值的演示项目。但他无法替企业决定哪些错误可以接受、哪个部门应当让出权力，以及自动化失败后由谁负责。AI转型牵涉预算、责任和利益调整，代码只能处理其中一部分。外部FDE会长期存在，因为模型和工具还在变化。但在一项具体业务中，FDE不应成为永久岗位。项目成熟后，日常运营要回到内部团队，常见需求要进入标准产品，低阶的数据转换和故障排查还会逐渐被AI接管。Palantir已经推出能够操作Foundry、管理代码库和修改数据转换的“AI FDE”，人类FDE的工作将更多转向业务判断、权限协调和异常处理。一个FDE项目真正完成，可以看三个结果：外部工程师离开后系统仍在使用，内部团队能够独立修改，供应商服务下一位客户时不必从头再来。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
