用途：① 内部 FDE 团队组建对齐材料（直接可发团队）；② 第 21 篇公众号文章研究底稿素材。 日期：2026-09-23。来源边界：全部事实来自 Palantir 官方文档 4 页 + 招聘/公告来源（S1/S2/S16/S17，同第 19 篇研究底稿），未做客户环境实测。
先拆最大的误区：FDE 有两个指代，混掉就全错了
| 指代 | 是什么 | 依据 |
|---|---|---|
| FDE（人） | Forward Deployed Engineer，驻客户现场的前置部署工程师，一个岗位/小团队模式 | Palantir 招聘 JD（S1 FDSE、S2 Deployment Strategist）、2021 AWS 技术博客署名（S16）、2026-03 埃森哲×微软 FDE 实践（S17） |
| AI FDE（产品） | 运行在 Foundry 之上的交互式 AI 智能体，把自然语言翻译成 Foundry 平台操作 | Palantir 官方文档 foundry/ai-fde/*（S3–S6） |
公司如果拿 AI FDE 的产品文档去当人类 FDE 岗的说明书，方向就偏了。 两份文档回答的问题完全不同：
- 人的 FDE 文档回答：谁去客户现场、小团队怎么配、对什么端到端负责
- AI FDE 文档回答：平台上的 AI 智能体怎么安全地替用户操作 Foundry
一、人类 FDE 岗位：Palantir 原始定义（来自招聘与公开实践）
从 Palantir 自己的招聘 JD 能提取的定义要素（S1/S2）：
- 面向客户、面对开放问题——不是领任务单，是客户带着未结构化的业务问题来。
- 小团队、端到端责任——从客户数据接入、业务语义定义、原型，到上线后的采用，一个小组负责到底，不是分段外包。
- 与产品团队协作回流——现场发现的可复用需求要推回产品，不是每个客户重复造轮子。
- 业务语言 + 工程能力都要——能跟客户业务负责人对话，也能自己写代码交付。
时间线证据（严格限定用途）： - 2021-09 AWS APN 博客署名 Palantir FDE（S16）：证明 2021 年岗位已存在。不推定起源年份。 - 2026-03 埃森哲与微软宣布建立 FDE 实践（S17）：证明 AI 落地潮下该模式在被其他公司复制。不引用”全球爆火”幅度。
一句话：FDE 是”把工程师派到业务问题旁边”的交付模式，核心价值在现场判断 + 端到端负责 + 能力回流，不是”会写代码”或”会用 AI”。
二、AI FDE 产品：官方文档四页逐条拆解
官方一句话定义（S3）： > AI FDE, the AI-powered forward deployed engineer, is an interactive agent that operates Foundry for you through conversational commands.
它不是独立机器人，是 Foundry 平台内的一个操作型智能体。五个设计要点（这是真正该抄的”作业”）：
1. 权限模型：不建服务账号，以你的身份行动（S5）
- 不是独立 bot/服务账号，用你现有的 Foundry 会话。
- “你建不了仓库，它也建不了；你改不了对象类型，它也改不了”；权限报错和你手动操作完全一样。
- 每一次 API 调用都带你的身份，审计日志按你归属；LLM 用量也按个人账号计量。
含义：AI 不是员工，是你的手。责任永远在操作的人身上。
2. 闭环操作：行动 → 观察 → 验证 → 决定下一步（S3）
- closed-loop 模型：执行动作后观察结果，用反馈决定下一步。
- 内置自验证动作：跑 transform preview 验证转换代码、跑 function preview 验证函数行为、查 CI 检查验证代码仓库里的代码。
含义：负责任的 AI 不是”一次生成”，是”干完自己查一遍”。
3. 模式（Modes）+ 能力（Capabilities）：上下文管理 = 最小权限 + 专注（S4）
- 9 个模式（数据集成/数据连接/本体编辑/函数编辑/探索/治理/机器学习/OSDK React/平台问答）决定”在干什么任务”：加载对应文档 + 开放对应工具。
- 能力（capabilities）是细粒度工具，分 agent 能力（切换模式/请求澄清/生成计划/查文档/管理自己的上下文）和领域能力（文件系统/笔记/方案设计/执行动作）。
- 官方理由：写 Python transform 的 agent 不需要治理或 React 工具——无关上下文会稀释推理（“context pollution”）。
含义：工具不放开给 AI，按任务发。
4. 默认走分支提交：永远不直改主干（S3/S6）
- 默认所有变更以 Global Branch proposal 或代码仓库 PR 形式提交给人审。
- 建议开启 Global Branching 支持本体编辑。
5. 保守分级审批（S5）
| 类别 | 例子 | 审批要求 |
|---|---|---|
| 每次都要批 | 执行本体动作、创建应用/组件、发布、打 tag | 逐次 |
| 分支感知 | 文件编辑、数据集构建 | 功能分支自动通过；受保护分支必须批 |
| 自动通过 | 搜索、读定义等只读操作 | 无 |
- 默认值”maximally conservative”：任何可能影响生产的都不自动批。
- 会话可预批（scoped to branch/project），但写操作没有用户同意就不会发生。
最佳实践补充（S6）
- 生产前必须验证：审查生成代码、用代表性样本数据测试；
- 只给必要的工具和上下文（多余上下文/工具 → 次优或错误动作）；
- 大任务拆小、迭代开发；AI 适合快速原型，生产质量 = AI 打底 + 人工精修；
- 用 AIP Evals 跟踪函数性能变化；
- 基础设施约束：人一次做一个操作、会停顿；AI 几秒一个、几分钟几十个操作、多会话并行——要按机器速度评估存储读写/GPU/容量，否则暴露瓶颈。
三、对照自查：组建 FDE 团队最容易偏的 5 个理解点
（对照第 19 篇内部架构图的评议结论：该图偏工具供给视图，缺业务价值负责人、数据接入语义、动作权限、评测验收、产品化维护）
- 把产品文档当岗位说明书。人类 FDE 的定义看 JD 和交付模式（面向客户/端到端/小团队/回流）；AI FDE 文档描述的是平台智能体。团队组建文件里如果直接引用 AI FDE 文档当岗位职责，说明混了。
- 买工具 = 建团队。AI FDE 的价值依赖 Foundry 的底座：Ontology（对象/关系/动作）+ 权限体系 + 分支评审 + 审计。没有底座，“FDE 智能体”退化成聊天框。对应第 19 篇判断：算力和代码入库必要但不充分。
- 给 AI 独立账号/超级权限。Palantir 设计明确禁止：无服务账号、无提权、操作全归到人。自查：公司 AI 助理有没有独立超管账号？有的话，这是第一治理风险——出事了无人可审计、无人负责。
- 让 AI 一次性直改生产。闭环自验证 + 分支提交 + 保守审批是 Palantir 的”负责任的 AI”标准。自查：AI 工具改生产数据/直接发布时，有没有 preview→PR→审批这条链？没有就是在安全框架外裸奔。
- 按人的工作量评估算力。AI 是机器速度 + 多会话并行。统一采购的算力/GPU/存储，评估口径必须是”高频并行操作”，不是”多少人用”。
四、一页对齐清单（团队内部用）
来源
| ID | 来源 | 允许支持 |
|---|---|---|
| S1 | Palantir FDSE 招聘 JD | 面向客户/开放问题/小团队/端到端/产品协作 |
| S2 | Palantir Deployment Strategist JD | 业务问题/数据/采用与工程协作 |
| S3 | AI FDE Overview（官方文档） | 交互式智能体定义、闭环操作、分支提案、上下文管理、模型支持 |
| S4 | AI FDE Modes and capabilities | 9 模式 + agent/领域能力、上下文聚焦理由 |
| S5 | AI FDE Security and governance | 用户身份操作、无服务账号、分级审批、会话隔离、审计与归因 |
| S6 | AI FDE Best practices | 生产前验证、最小工具/上下文、迭代、AIP Evals、基础设施约束 |
| S16 | AWS APN 博客 2021-09 | 2021 年岗位已存在（不推定起源） |
| S17 | 埃森哲新闻室 2026-03-18 | 埃森哲×微软 FDE 实践（不推定规模/热度） |
边界声明：以上均为 Palantir 官方设计与招聘表述，不是独立效果评估；多篇 Palantir 页面不构成相互独立的商业成效证据。本文不主张 Palantir 的 ROI 或行业优越性。中国企业的组织适配沿用第 19 篇条件分析（授权、数据、资源、责任权限），不泛化。