FDE / Agent Delivery / Loop Engineering

FDE：企业 AI Agent 落地的缺失一环

从客户现场的复杂现实，到可部署系统、行为评测和可复用产品能力。

Forward Deployed Engineer WORKBUDDY SED Delivery Evals
Optimized HTML deck / 16:9 fixed stage
01 / 17
Core Thesis

FDE 不是高级实施顾问，而是产品学习回路

Agent 的难点不在 Demo，而在把现场失败转成产品资产。

现场数据、权限、流程、隐性规则、异常场景
工程工具、集成、日志、人工审批、上线稳定性
产品evals、templates、skills、connectors、roadmap
02 / 17
Why Now

企业 AI 卡住的位置，通常不是模型层

数据不稳

知识库未同步、字段缺失、权限隔离、历史数据不可用。

流程不清

谁能审批、何时转人工、失败后谁负责，往往没有被写下来。

行为不可测

改了 prompt 后不知道变好还是变坏，缺少行为回归测试。

Key point: AI Agent deployment is a workflow and trust problem, not only a model problem.
03 / 17
Definition

FDE 是嵌入客户现场的工程闭环角色

Observe进入真实业务现场，理解工作流和阻塞。
Build用代码、工具和平台能力构建可用原型。
Deploy在受控生产环境中试运行和交付。
Measure观察采纳率、失败案例和人工修正。
Productize沉淀为 evals、skills、templates 和平台能力。
04 / 17
Role Boundary

FDE 和顾问、售前、产品工程师不一样

顾问

交付项目，输出方案和实施结果。

售前/解决方案

证明价值，配置演示，帮助成交。

产品工程师

面向通用产品路线图开发能力。

FDE

在客户现场拥有代码和产品判断，把局部问题转成可复用能力。

05 / 17
Origin

Palantir 把 FDE 做成复杂企业软件的操作系统

复杂、高价值、非标准化的问题，不能只靠远程产品路线图解决。

嵌入现场

直接进入客户任务环境，接触真实用户和数据。

横跨多域

软件、数据、流程、领域知识和用户采用同时处理。

快速反馈

现场失败能快速回到工程和产品决策。

Sources: Palantir FDSE blog and Palantir job description.
06 / 17
Concrete Case

Salesforce 案例：一个 Agent 试点为什么卡住？

1

目标

订位平台上线 B2B 客服 Agent，回答客户服务问题。

2

问题

Agent 有时答不上来，知识更新未同步。

3

动作

FDE 诊断数据链路，协同产品团队修复 Agentforce / Data 360。

4

结果

Salesforce 称一周内恢复，客户继续推出第二个 Agent。

Source: Salesforce, “Forward Deployed Engineers are helping customers launch AI agents”.
07 / 17
Lesson

这个案例的真正启示：失败在部署层

不是“prompt 写得不够聪明”
而是知识、数据、同步、权限和流程没有闭环
所以FDE 要同时懂客户现场、系统集成和产品反馈

Agent 落地不是模型接入项目

它是一个生产系统调试、信任建立和组织流程改造项目。

08 / 17
Onsite Method

FDE 到客户现场后，按 7 个阶段推进

0进场准备客户背景、流程假设、访谈计划、数据访问清单。
1真实流程发现shadow 一线用户，收集例外流程、痛点和样本案例。
2问题定义把“要 AI”翻译成可部署的 Agent scope 和成功指标。
3数据工具审计检查知识、检索、API、权限、日志和 connector 缺口。
4最小可用部署配置 Agent、skills、expert rules、审批和 fallback。
5受控试点只读/建议模式先跑，记录失败、接管、采纳和修正。
6产品化沉淀把失败变 eval，把经验变 template，把脚本变 connector。
7持续运营监控漂移，更新 skills/evals，完成客户自运营交接。
Key message: FDE 不是到现场“做需求”，而是把真实流程拆开并放进可验证闭环。
09 / 17
Deliverables

每个阶段都要留下可复用交付物

流程发现当前流程图、痛点清单、异常场景、样本案例。
问题定义Agent scope、成功指标、风险边界、人工审批规则。
数据审计数据就绪报告、知识同步 checklist、工具集成图。
MVP 部署instructions、skills、expert profile、tool config、fallback。
生产试点pilot report、failure log、override analysis、go/no-go。
产品沉淀reusable skills、templates、eval suite、launch playbook。
平台反哺connector backlog、platform gaps、WORKBUDDY roadmap。
持续运营运营看板、漂移监控、月度复盘、handoff package。
PPT thesis: 现场交付的终点不是项目验收，而是 WORKBUDDY 的资产增长。
10 / 17
WORKBUDDY

WORKBUDDY 应该成为 SED 的交付操作系统

不要把 SED 变成客户定制开发队。

正确定位：基于 WORKBUDDY 的 Agent 专家方案工厂。

WORKBUDDY 平台层模型、工具、流程、知识库、权限、审批、日志、渠道
SED 交付资产层experts、skills、templates、evals、playbooks、connectors
客户场景层客户知识、业务流程、系统连接、本地策略和权限配置
11 / 17
Delivery Strategy

优先做专家和技能，最后才做平台二开

Experts专业判断视角：法务、客服、销售、投研、供应链。
Skills具体任务能力：分类、草稿、审核、升级、抽取。
Templates场景工作流：客服分流、销售跟进、项目周报。
Evals行为测试：正确、拒答、升级、隐私、边界条件。
Dev仅当缺少共性连接器、权限、日志、部署能力时二开。
12 / 17
Reusable Package

一个 SED 交付包应该长这样

1 个行业 Expert

定义专业视角、风险意识、判断原则和升级边界。

若干业务 Skills

把任务步骤、输入输出、工具调用和人工审批写清楚。

1 个场景 Template

把流程节点、角色、工具、知识库和输出格式标准化。

一组 Evals

从现场失败和人工修正中沉淀行为回归测试。

上线 Playbook

知识准备、灰度试运行、人工接管、周复盘。

必要 Connector

CRM、ERP、飞书、企微、Jira、GitHub 等共性连接器。

13 / 17
Decision Rule

什么时候才值得二次开发？

值得做平台二开

缺少共性连接器、权限审批、执行日志、eval 框架、多租户隔离、统一工具注册、版本部署能力。

不应做私有定制

只服务单个客户的特殊流程，应优先表达为配置、skill、template 或客户策略，而不是散落代码。

判断标准：这次交付留下的是代码债，还是平台资产？
14 / 17
Loop Metrics

SED 不应只看项目数量，要看平台复利

Reusable
Skills
Templates
Reused
Eval
Cases
Launch
Speed
Custom Work
Absorbed
每做一个客户，WORKBUDDY 是否变得更强？
15 / 17
Roadmap

建议从低风险、高频、可评测场景切入

客服工单

分类、回复草稿、投诉升级、知识检索。

销售线索

需求抽取、优先级评分、跟进建议、CRM 更新。

项目管理

会议纪要、任务提取、进度追踪、周报生成。

行业研究

文章 intake、事件抽取、公司映射、观点草稿。

Selection rule: 高频、输入明确、输出可检查、有反馈信号、出错成本低。
16 / 17
Final Takeaway

未来竞争的不是 Agent Demo，而是部署闭环

模型创造可能性，FDE 创造生产影响；evals 创造组织记忆，产品吸收创造规模化优势。

Models create possibility FDE creates production impact Evals create memory Product absorption creates scale
17 / 17