Forward Deployed Engineer（FDE）正在成为企业 AI 的标准配置：模型公司派工程师进入客户现场，花几个月搭建工作流，再把包含大量人工服务的收入记成 ARR。
这已经形成一种很稳定的商业模式：先卖平台，再补交付；先确认收入，再用下一轮融资扩大工程团队。融资故事也顺势切换成“agentic”“autonomous”和“operating leverage”。
但 FDE 真正照亮的，恰好是自主 Agent 尚未跨过产品化门槛。
最直接的检验只有一个：撤走驻场工程师，客户还能不能继续获得付费产品承诺的东西？如果不能，那么自主性主要存在于发布会和融资材料里，真实交付仍由人承担。
Agent 的自主性，通常卡在系统边界
按我的理解，FDE 并不是单纯替客户配置软件，而是在替模型做三件产品本应封装掉的事：
第一，把客户内部的数据、系统和权限接到 Agent 上。
第二，把一句模糊目标翻译成模型可执行的步骤、工具调用和异常处理规则。
第三，在模型跑偏时继续修正流程，必要时用工程师的经验兜底。
这三步都合理。问题在于，它们如果无法沉淀为通用产品能力，就会变成每个客户都重新做一遍的定制工程。
企业软件最难自动化的部分通常不在模型生成一段文字，而在上下文是否完整、工具是否可用、权限是否正确，以及失败之后谁来接管。模型可以规划，Agent 可以调用工具，但真实工作流里仍有大量隐含规则：
- 什么条件满足后才能执行下一步； - 哪些结果可以被信任； - 哪些异常要重试，哪些异常要交给人； - 换一家客户时，哪些规则可以复用。
模型越接近真实业务，这些规则的权重越高。规则数量增长到一定程度，驻场工程师就从“帮助客户配置”变成了“维持系统运转”。
这也是 FDE 模式最难处理的地方：它既可能帮助团队发现通用产品缺口，也可能让定制交付被收入数字遮住。
真正值得看的并非“需不需要工程师到现场”，而是现场产出的东西有没有回流到产品。
如果驻场工程师最后只留下客户专属流程、接口和补丁，那么每签一个客户，产品就多背上一套服务负担。销售侧看到的是平台收入，财务侧看到的却是持续膨胀的交付成本。
我更关心工具边界，而不是驻场人数
我做过一个把网页平台能力集成成 MCP、交给 AI 执行的项目。那类工作最值得注意的地方，同样不在“让模型自己点按钮”，而在于怎样把平台能力变成 Agent 可以稳定调用的工具。
从工程上看，工具边界清楚、可组合，模型才有机会自己完成工作；工具语义含糊、权限和异常都靠人解释，Agent 就会很快退回成一个需要工程师陪同的聊天框。
这和 FDE 形成了直接对照。
驻场模式倾向于为客户现场补齐上下文、连接系统和处理异常，交付速度取决于工程师能力。产品化路径则要求把反复出现的能力收回平台，让每次交付复用同一套接口、权限和执行机制。
我更倾向后者，未必是因为它看起来更像“AI 公司”，而是因为它把规模化的难题放到了可以被工程检验的位置：
- 新客户增加时，哪些能力无需重做？ - 使用次数增加时，交付成本是否下降？ - 驻场工程师的产出，究竟沉淀成产品，还是只沉淀成客户专属代码？ - 当客户不再购买驻场服务时，产品能否独立完成交付？
这组问题会直接改变一个 AI 公司的成本结构。
ARR 不等于软件收入
FDE 叙事最聪明的地方，是把人的收入装进软件的估值框架。
客户为部署、集成和持续调整支付费用，这笔钱可以进入 ARR；但只有当交付成本随着客户数量和使用次数增长而下降，它才具有传统软件业务的规模特征。若新增收入需要近似同比增加工程人员，毛利、下一客户的 onboarding 成本和公司整体经营杠杆都会受到限制。
FDE 模式还有一个容易忽略的时间差。
产品团队可以在收入确认之后继续补能力，工程团队也可以用下一轮融资覆盖当前交付缺口。融资顺时，人员扩张可以伪装成增长；一旦增长放缓，驻场团队就会从产品缺口的放大器变成固定成本。
因此，判断一家公司的 FDE 密度，不能只看它签了多少客户，还要看服务收入和软件收入分别如何交付。
更有区分度的问题包括：
1. 驻场项目中有多少工作已经进入标准产品？ 2. 一个新客户需要多少专属工程投入？ 3. 驻场工程师是在调试客户环境，还是在调试尚未成立的产品？ 4. 客户停止购买实施服务后，平台还能否独立运行？
如果答案都指向客户现场，说明公司仍然在出售“软件许可 + 咨询实施”。这本身可以成为好生意，只是它不应该自动获得纯软件公司的估值方式。
FDE 不一定是失败，也可以是产品侦察器
我也不认为驻场工程师没有价值。
很多企业 Agent 的真实问题并不是模型不够强，而是模型根本不知道客户业务怎样运转。工程师进入现场，可以把需求、使用反馈和失败样本带回来，帮助产品团队找到应该标准化什么。
危险发生在反馈没有回流机制的时候。
驻场工程师越能干，现场交付越顺，产品团队越可能误以为平台已经成熟。工程师亲手补上的每个异常都解决了当期问题，也在掩盖平台边界依然脆弱的事实。
所以 FDE 是否有价值，不能只看客户能不能上线，还要看驻场工作有没有减少。
一个健康的方向是逐步缩短现场介入：
- 高频且可复用的任务进入标准工具； - 常见异常进入自动恢复机制； - 权限、审计和可观测性进入平台； - 低频且高度定制的问题才保留人工交付。
这样看，驻场工程师的角色应该从“维持客户运转”转向“减少自己下一次必须到场的理由”。
真正自主的企业 Agent，不是完全不需要人参与，而是产品价值不依赖工程师长期蹲守。
那么问题就很具体了：FDE 团队产出的每类客户定制里，有多少会在下一个客户身上直接复用？如果复用比例长期没有提高，Agent 的自主性究竟在客户现场，还是只在公司的融资叙事里？
---