Palantir

FDE分工：Echo、Delta、FDPM分别是什么？

2026 年 9 月 15 日

本文解析FDE（Field Deployment Engineer）体系中的三类核心能力：Echo负责识别真实、高频、可衡量且人工可快速兜底的业务场景；Delta负责将场景工程化为可长期运行的生产系统；FDPM负责项目推进与协同。强调三者是能力维度而非固定岗位，一人可兼任，取决于项目复杂度与个体能力组合。

很多人一听到 FDE，就会顺着一套角色图来理解：Echo 负责业务，Delta 负责开发，FDPM 负责项目推进。

但在我看来，这三者首先不是必须一一对应的岗位，而是三类不同的能力：谁来判断该做什么，谁来把它做出来，谁来把客户和项目推进下去。

一个人能不能兼任，取决于他是否同时具备这些能力，以及眼前项目和行业的复杂度，而不是组织图上有没有三个名字。

先说明一下：FDE 目前没有特别统一的定义。Echo、Delta、FDPM 是 Palantir 最早提出的三种角色，或者说三类能力；它们不代表每家公司都有这些固定岗位。

Echo：先确认这是不是一个值得做的场景

Echo 更像业务专家。

他要做的不是把客户说的每个需求都记下来，而是先判断：这是不是一个真实存在、值得投入的业务问题。

一个高价值场景，通常至少有几个特点：

一线同学真的在这样做，而不是经过几层转述后想象出来的需求。
它高频、消耗人力。
上 AI 之后，结果能客观衡量。
错误要么有足够容忍度，要么能由人工快速兜底。

这里的“快速兜底”很关键。

如果 AI 产出以后，人工还要花和原来亲自做一遍差不多的时间去审核，那它没有真正减少工作量。更合理的情况是：人只需要快速判断，处理少数例外。

业务专家的价值，尤其体现在陌生行业里。

比如做制造业项目时，如果听不懂行业术语、不知道默认的业务常识，也抓不住对方真正想解决的问题，就很容易问不到点子上，最后找偏场景。真正懂业务的人能和一线人员高频沟通，顺着一个问题继续追下去，识别哪些才是高价值的机会。

Delta：把可行的场景做成能长期运行的系统

Delta 更像一名全栈工程师。

他接到的不是一句模糊的“帮我做个智能体”，而是已经被翻译过的业务场景：要解决什么问题，什么结果算成功，哪些环节必须保留人工。

Delta 要把它先做成 Demo，再逐步推向生产环境。

Demo 能跑，不等于能上线。

一个 Demo 可以暂时跳过权限、数据安全、稳定性、性能、可维护性和可扩展性；但这些问题到了生产环境，一个都绕不开。甚至在做 Demo 时，就应该先判断这条路有没有走到生产环境的可能。一个未来根本无法工程化的 Demo，再漂亮也没有意义。

所以 Delta 不只是“把功能写出来”。他还要考虑系统集成、测试、灰度发布、异常处理，以及怎样尽量降低对线上环境的影响。

FDPM：把项目持续往前推

FDPM 相当于前线部署项目经理。

他负责整个项目的推进、协调和进展管理，也可能主动与企业方做协同和汇报，并处理项目过程中出现的问题。

在很多 FDE 团队里，有经验的工程师或开发者本身就具备项目管理和推进能力。因此，常见的协作形式是：一位业务专家，加上一位兼任项目经理的全栈工程师。

一个人能处理得过来，就可以兼任；处理不过来时，再把这部分工作分出来。

AI 改变的，不只是开发速度

以前把能力拆给多人，很大一部分原因是工作量太大。

写代码、跟客户沟通、整理文档、收集信息、做方案，这些事都需要大量时间。现在，AI 能帮助全栈工程师更快开发，也能帮助不了解行业的人提前补基础认知：查术语、整理资料、把录音转成文字稿，再从对话里归纳问题。

这不代表 AI 能让一个人立刻成为行业专家。

但它确实让一个原本不懂业务领域的人，更快获得基础理解，成为“半个业务专家”。原来被不同角色分别承担的一些工作，现在可以被一个更强的个人能力组合覆盖。

我自己在电商行业，就可以把这三类事情合在一起做：既理解场景，也能做工程实现，还能推进项目。

但换到偏制造业的项目，因为我对行业领域知识还不够深，就必须有真正懂业务的人配合。这时更适合的组合，是业务专家加上一位兼任项目推进的全栈工程师。

分工的目的，不是把组织图画得更复杂

无论是一人兼任，还是多人协作，最终都不只是为了完成一个客户项目。

Echo 更适合把反复出现的业务问题和行业判断沉淀下来；Delta 在现场也会发现哪些能力值得复用。只有把这些经验回流成 Skill、模板、测试方法或产品能力，下一次交付才可能更快、更稳。

所以，对 FDE 团队来说，更值得先问的不是“我们要配几个人”，而是：

这个场景是否真实、高频、可衡量，并且能由人工快速兜底？
团队里是否有人既懂这个行业，又能把问题推进成可运行的系统？
这次现场交付留下的东西，下一位客户能不能复用？

AI 会让更多能力合在一个人身上。

但遇到陌生行业、复杂业务和真正的生产环境，能否找对问题、做成系统、推动协同、沉淀经验，仍然决定了这是不是一次有效的 FDE 落地。

JOTO 企业落地观察

对企业部署意味着：FDE 角色设计不应照搬 Palantir 模型，而应基于自身行业知识储备与工程成熟度动态配置。当企业缺乏垂直领域业务专家时，需优先补足 Echo 类能力，否则易陷入伪需求陷阱；若工程化能力薄弱，则 Delta 的职责不可简化为 Demo 开发。
这类系统的取舍在于：是否将‘人工快速兜底’作为场景准入硬约束。未满足该条件的项目，即使技术上可实现，也大概率因审核成本过高导致 ROI 为负——这对 RAG 知识工程提出明确要求：必须预置可解释、可追溯、可人工干预的决策路径。
对 FDE 驻场共创模式而言，关键产出不仅是交付系统，更是可复用的行业判断框架与工程化模板。若每次驻场仅解决单点问题而未沉淀为 Skill 或测试资产，团队将陷入重复劳动，无法形成规模化交付能力。
AI 工具虽能加速 Delta 的开发与 Echo 的认知构建，但无法替代 FDPM 在客户侧建立信任、协调资源与管理预期的能力。企业在组建 FDE 团队时，需明确区分‘技术执行’与‘客户协同’两类动作，后者仍高度依赖人的软性经验。