导读 过去几个月，FDE 在国内 AI 圈迅速升温。模型越来越强，企业 AI 落地却没有同步变简单。模型会写代码、调用工具、分析数据，可一进企业，还是要面对内部数据库、业务口径、权限系统、旧软件，以及大量只存在员工经验里的隐性知识。模型和真实业务之间，仍然需要一群人把它们接起来。

这正是 Forward Deployed Engineer 被重新关注的原因。从近期公开岗位看，火山引擎已经出现 Forward Deployed Engineer ／ 现场部署工程师，腾讯也出现“AI 前线部署工程师 FDE”这类岗位命名。至少从组织和招聘动作看，FDE 已经不再只是 Palantir 式的小众概念，而是在进入国内企业 AI 的交付体系。

主要内容包括以下几个部分：

1. Palantir 先接手的，不是 FDE 的判断，而是执行链

2. AIP Evolve 开始让一群 Agent 自己优化 Agent

3. 这不只是 Palantir：AI FDE 已经开始改变真实交付流程

4. 真正不会被轻易接走的，是“定义正确”

图1｜Palantir AI FDE 官方总览图

国内还在补 FDE，长期把 FDE 作为核心产品开发方法的 Palantir，已经开始把 FDE 本身做成 Agent。Palantir 长期把 Forward Deployed Engineering 作为自己的产品开发机制：工程师深入客户现场，再把真实问题不断反馈给核心产品团队。官方甚至把这套方法形容为“human equivalent of backpropagation”。

2026 年 3 月 12 日，Palantir 的 AI FDE 正式 GA。它已经可以直接在 Foundry 中做数据转换、管理代码仓库、维护 Ontology，并通过自然语言把任务转换成具体的 Foundry 操作。9 月 8 日，Palantir 又推出 AIP Evolve：用户只需要给出优化对象、目标、验证方法和允许修改的边界，一组 AI FDE 就可以自己寻找方案、修改现有 AI System、跑 Eval，再把 Proposal 交给人审核。

Palantir 正在把 FDE 的工作拆开。 那些可以被 Context、Tool、Eval、Permission 和 Branch 明确定义的工作，开始逐渐交给 Agent；目标怎么定、什么结果算正确、什么修改能够进入生产，则继续留在人手里。

01 Palantir 先接手的，不是 FDE 的判断，而是执行链

真人 FDE 到客户现场，并不是每天都在做抽象的“业务理解”。大量时间其实消耗在非常具体的工程工作里：找数据、理解表结构、建 Pipeline、修改业务对象、写 Function、维护代码仓库、测试，再根据结果回来修改。这些工作有一个共同特点：有工具、有状态、有反馈，而且结果往往能够验证。 AI FDE 最先开始自动化的，正是这一层。

它并不是一个默认拿到全部企业数据、全部工具的超级 Agent。Palantir 反而强调限制它看到的东西：根据当前任务加入 Dataset、Function、Branch、Object Type 或文档，只给完成任务真正需要的 Context 和 Tools。官方最佳实践也明确建议，只提供必要的工具和上下文。

AI FDE 甚至按照任务拆成不同 Mode。做 Data Integration，就加载数据集成相关文档和工具；修改 Ontology，就进入对应模式；写 Function 时，再切到 Function Editing。Agent 还可以在执行过程中自己切换 Mode、调整 Capability。Palantir 给出的理由很直接：一个写 Python Transform 的 Agent，并不需要同时拥有 Governance 或 React 工具。无关能力越多，越容易让模型分心或者调用错误的工具。

说到底，这是一条很实用的企业 Agent 原则：不是 Context 越多、Tool 越多越强，而是要让 Agent 当前能够操作的世界尽量小。

图2｜AI FDE Modes：不同任务只加载对应能力

第二个关键是闭环。AI FDE 写完一个 Function，并不是把代码吐出来就结束。它可以创建测试、运行 Eval、读取失败结果、诊断问题、修改 Function，再重新跑一次。Palantir 在 4 月进一步把 AIP Evals 接进 AI FDE 后，这套“写—测—看失败—再改”的流程已经可以直接在 Agent 内完成。整个执行方式越来越接近：Action → Observe → Evaluate → Adjust → Action。

这也是为什么 FDE 的一部分工作越来越适合被 Agent 接管。模型未必比真人更懂一家公司的业务，但只要某项工作能够形成稳定的执行—反馈—纠错闭环，自动化的条件就已经出现。

与此同时，Palantir 没有因为模型变强就取消工程边界。AI FDE 沿用当前用户身份，没有独立的超级账号；人没有权限访问的数据，AI FDE 同样不能访问。写操作默认要求用户确认，高风险动作需要每次 Approval；Branch 内的部分修改可以按范围预授权，只读操作才默认放行。所有操作继续进入 Foundry 原有的 Audit Log。

图3｜AI FDE Tool Approval：执行操作前由人 Allow ／ Reject

代码和 Ontology 的修改也不是直接冲进生产环境。Palantir 建议 AI FDE 默认在 Branch 中工作，通过 Global Branch Proposal 或 Pull Request 进入 Review，再由人决定是否合并。

所以 Palantir 的思路不是等待一个“永远不犯错”的 Agent。恰恰相反，它是在承认 Agent 会犯错的前提下，把企业环境改造成：Agent 可以犯错，但错误被限制在可验证、可审计、可回滚的边界里。 到这里，AI FDE 主要还是在替人执行。AIP Evolve 真正往前走的一步，是连“下一步应该改什么”，都开始交给 Agent 搜索。

02 AIP Evolve 开始让一群 Agent 自己优化 Agent

过去，人会告诉 AI FDE：换掉这个模型，修改这段 Prompt，把这个 Workflow 调一下。AIP Evolve 把人的输入进一步抽象成了四件事：要优化什么、目标是什么、怎么验证、允许改到什么程度。

Palantir 官方举了一个库存分配 AI Workflow 的例子。这个 Workflow 能根据订单决定库存如何分配，但团队认为 Compute Cost 太高。用户把“降低成本”设为 Goal，选择 10 个有代表性的 Test Case，允许系统修改 Model 和 Prompt，同时规定最多迭代 5 次。

接下来，人不再逐项告诉系统应该怎么改。AIP Evolve 会调度不同 AI FDE，先检查现有 Workflow，再创建测试、尝试 Model Swap、调整 Prompt、运行 Evaluation。整个过程还会生成 Agent Graph，让人看到 Analysis、Test Creation、Model Swapping、Evaluation、Prompt Engineering 和 Proposal Writing 等不同 Specialist Agent 在做什么。

官方示例里，这套系统最终运行了 3 轮。最后的 Proposal 建议把 GPT-4o 换成 GPT-5.4 Mini，同时给两个 Prompt 加上 Guardrail。修改前后 10 个测试全部通过，但平均 Compute Cost 从每次调用 204.6 compute seconds 降到 72.4，下降 65%。

65% 本身不是最重要的。重要的是优化过程变了。过去，一个工程师发现成本高，需要自己分析：是不是模型太贵？Prompt 是否可以缩短？换小模型会不会掉准确率？要补什么 Guardrail？改完之后再手工测试。

图4｜AIP Evals：Baseline 与新版本逐 Case 对比

现在，人只定义一句更高层的问题：“我要成本下降，但不能出现明显 Regression。” 具体在哪个 Model、Prompt 和配置组合上能满足这个条件，开始由 Agent 自己搜索。

这已经不太像普通 Coding Agent。Coding Agent 更多回答的是：这个任务怎么完成？ AIP Evolve 开始回答的是：在 Cost、Latency、Quality 等多个约束之间，哪一组系统配置更优？

而真正让这件事成立的，也不是单纯多开几个 Agent，而是 Eval。AIP Evals 可以定义 Test Case、Evaluation Function 和 Expected Output，也可以比较不同模型、不同版本，甚至观察同一个非确定性模型多次运行的方差。只有“好”能够被写成机器可以判断的标准，Agent 才能知道一次修改到底是优化，还是另一种 Regression。

所以 Self-improving Agent 真正进入生产以后，首先暴露出来的并不是模型智力问题，而是一个更现实的问题：企业能不能先把“什么叫变好”定义清楚。

03 这不只是 Palantir：AI FDE 已经开始改变真实交付流程

类似的变化已经出现在国内企业 AI 的实际交付中。

DataFun 8 月 26 日的一场企业 Agent 圆桌里，一组企业实践显示，AI FDE 带来的第一阶段变化，并不只是“一个人干得更快”，而是开始把原来依赖人工串行推进的 FDE 工作拆成并行任务。

悦点科技团队分享，在实际项目中，过去 FDE 从业务访谈、材料搜集、本体模式发现到数据 Pipeline，往往一环套一环；引入 AI FDE 后，真人还在做业务访谈，AI 已经可以同步抽取信息，数据调研过程中也能并行探查数据库设计、API 文档和主数据。过去一环套一环的流程，被拆成多路同时运行。

这比一句“AI 提高 FDE 效率”更具体。因为它改变的不是单个环节快了多少，而是整个项目怎么推进。过去更像：访谈 → 文档 → 建模 → 数据 → Pipeline → 验证；现在则开始变成：访谈 ／ 文档 ／ 数据探查 ／ API 分析并行进行 → 汇入建模与验证。人的工作带宽不再完全决定项目有多少环节能够同时启动。

圆桌里还有一组更具体的数据。在一个 IPO 招股说明书相关项目中，受访团队估计，如果按照传统人工方式，从理解业务到完成本体建模，至少需要半年。

引入 AI 后，他们利用历史招股说明书和已有数据体系自动抽取业务对象、关系和核心指标。按照受访团队的说法，大约两周已经完成了 70%—80% 的初始业务对象、关联和核心指标梳理。但这并不是“两周完成整个项目”。指标之间真正的计算逻辑还需要专家调整，部分动态业务逻辑也很难一次性做对；最终做到足以支撑完整招股说明书报告，大约仍然用了两个月，尤其定性描述仍然需要专业人员参与。

这个案例反而比“AI 替代 FDE”更能说明问题。AI FDE 并没有一下子消灭一个完整岗位，而是先把那些耗时间、结构化程度高、容易验证的前置工作大幅压缩，再把人的时间推向判断密度更高的部分。

圆桌中，受访团队还提出了一个很直接的判断：如果所谓 AI FDE 最终仍然只是派更多真人按照传统 FDE 模式做咨询和交付，本质上只是给旧模式换了个名字；真正应该推进的，是把经典 FDE 工作尽可能 AI 化，让 AI 先快速完成从 0 到 1 的打样，再由人继续往正确方向修。

Palantir 和这组国内实践的起点并不完全一样。Palantir 已经开始让 AI FDE 自动优化 Model、Prompt 和 Workflow；国内这组企业级实践里，首先被自动化的是访谈信息抽取、数据探查、业务建模和交付过程。

但两边正在指向一个相似的规律：越能被描述成 Context、Tool、Workflow、Feedback 和 Eval 的 FDE 工作，越容易被 Agent 接走。

04 真正不会被轻易接走的，是“定义正确”

这也是为什么现在说“AI FDE 要取代真人 FDE”，仍然太早。AIP Evolve 看起来已经非常自动：它能换模型、改 Prompt、跑测试、连续迭代。但仔细看整个系统，会发现最关键的三件事仍然没有交出去。

第一件事，是定义 Agent 应该知道什么。模型面对公开知识时越来越强，但企业内部哪些业务规则、哪些数据关系、哪些历史经验必须进入 Context，并不是模型自己天然知道的。Context 少了，Agent 不理解企业；Context 太多，又可能带来干扰。真人 FDE 的工作开始从“自己查所有资料”，上移到“决定哪些信息应该进入 Agent 的工作空间”。

第二件事，是定义什么叫正确。这是 AIP Evolve 最核心的前提。降低 65% Compute Cost 很容易测，但真实企业业务远没有这么简单。客服 Agent 准确率提高了，但投诉率上升，算不算优化？供应链 Agent 平均成本下降了，但极端场景中的缺货风险增加，能不能接受？一个 Workflow 从十步变成三步，但遗漏了一项合规检查，到底是效率提升还是 Regression？这些问题最终都会落到 Eval。

而 Eval 并不是模型自己凭空创造出来的，它需要人把业务里的“对”和“错”变成 Test Case、Metric、Constraint 和可接受边界。

第三件事，是定义 Agent 可以错到什么程度。Palantir 之所以敢让 AI FDE 深入企业系统，并不是因为它认为模型已经足够可靠。相反，它保留了 Permission、Tool Approval、Branch、Pull Request、Human Review 和 Audit，把 Agent 的试错限制在一个受控环境里。

这可能才是 AI FDE 真正改变 FDE 的地方。过去，一个优秀 FDE 很大一部分价值来自亲手完成工作：写 SQL、调 Pipeline、接 API、Debug，把系统一点一点接进客户环境。未来，这些执行动作越来越多可以交给 Agent。真人 FDE 更重要的问题会逐渐变成：Agent 需要知道什么？什么结果才算正确？它被允许错到哪里？

图5｜AIP Evals 多次实验结果

所以，国内现在需要更多 FDE，和 Palantir 开始做 AI FDE，并不矛盾。企业 AI 越往真实业务走，越需要人第一次把隐性的业务知识、权限、流程和判断标准，翻译成机器能够使用的 Context、Tools、Workflow 和 Eval。

但这件事还有另一面。每完成一次 FDE 交付，也就留下了一套新的可学习轨迹：这个场景需要什么 Context，该调用哪些 Tools，什么情况应该停下来找人，什么结果允许进入生产。当这些经验不断被结构化，它们本身也就开始变成 Agent 可以继续执行的对象。

Palantir 现在展示的，可能不是“FDE 消失”，而是 FDE 的工作开始变得可编程、可验证，也因此开始可以被 Agent 接管。

以前，是 FDE 优化 Agent。现在，一群 Agent 已经开始优化 Agent。真正更难被自动化的，反而是最后那件事：定义什么叫做得更好。