埃森哲已经在场，FDE 来做什么？

你第一次参加企业客户的启动会，发现屋里懂技术的不只你一个。桌子对面坐着 Accenture 或 Deloitte 的团队，手里有签好的工作说明书（SOW）、时间表，还有自己的项目经理。你脑子里冒出的第一个问题是：那我来干什么？

这种情况越来越常见。2026 年 2 月 23 日 OpenAI 发布 Frontier 平台时，Accenture、Capgemini 等咨询公司作为合作伙伴加入，与 OpenAI 的前线部署工程师（FDE）团队协同工作。更早些时候，2025 年 12 月，Accenture 与 Palantir 组建了联合业务团队，其基础是 Accenture 2,000 多名熟悉 Palantir 的员工。

因此，与系统集成商（SI）协作已经成为 FDE 手艺的一部分，不再只是销售那边的事。做得好，你可以主导技术工作，而不必事事亲力亲为。

做得不好，会出现两种结果之一：你沦为 SI 的工单答疑台，或者成了他们在客户办公室里的对手。

两个团队，两种“完成”

乍看之下分工很清楚：SI 负责构建和集成，你是最懂平台的人。但双方的考核标准并不相同。

据 Webfuse 介绍，咨询项目的范围和方法由 SOW 事先确定，顾问按该范围的完成情况考核，咨询公司则跟踪人员利用率。

FDE 的考核标准则是生产环境中的真实使用情况，以及对工作流可衡量的影响。Entrans 是一家销售 FDE 服务的公司，其说法应视为一家之言。它认为，只有系统真正带来预期的业务结果，工作才算完成；成功也不按正常运行时间或 API 延迟这类传统服务等级协议（SLA）指标来衡量。

这两个里程碑之间的地带，往往无人签字负责。

Forgepoint Capital 解释了为什么这个缺口很难靠合同弥合：AI 项目的质量极难写进条款。它问道，如果双方连“好”是什么样都无法达成一致，又怎么能就 SOW 里的交付物达成一致？

这是观点，不是测量结果。但它解释了为什么最难定义的部分，包括评测、Agent 行为和模型错误处理，往往落到你头上，哪怕合同对此只字未提。Salesforce 的 Nick Johnston 说得很直白：Agent 时代的胜负取决于业务结果，而不是试点。

这并不意味着 SI 就是慢的一方。2026 年 8 月，Deloitte 宣布在一个 Salesforce 项目中把 FDE 直接编入解决方案交付团队。SD Times 也认为，FDE 是对传统顾问的补充而非替代，补的是顾问较弱的地方。头衔并不重要，重要的是谁对什么负责。

案例：一个处理保险理赔的 Agent

假设客户是一家保险公司，想要一个 Agent 阅读理赔案卷，建议批准或转交人工审核。

SI 的 SOW 对“完成”的定义是：Agent 与理赔管理系统完成集成，并通过 20 个场景的用户验收测试（UAT）。客户则希望把简单理赔自动化，前提是 Agent 的准确率至少达到 95%。

算一笔账。Agent 通过了全部 20/20 个 UAT 场景，因为它们都是正常路径（happy path）用例。但在由 200 份真实、已脱敏理赔案卷组成的评测集上，它只答对了 170 份，即 85%。按合同，项目已经结束；客户需要的结果却没有达到。

这里没有人做错事。SI 交付的正是合同上签的内容，只是合同衡量错了对象。你的工作是在第一周就发现这个缺口，而不是在上线当天才发现。

第一个工具是职责矩阵，要在任何人动手写代码之前完成：

领域	SI	厂商 FDE	客户
与理赔系统集成、身份认证、内部数据	主要负责	就 API 限制提供建议	授予访问权限
评测集与 95% 阈值	在 CI 中运行	设计并负责质量	标注数据，批准阈值
Agent 设计、模型错误处理	实现	主要负责	确认业务规则
平台限制与即将到来的变更	知情	主要负责	知情
上线后运维手册	主要负责	共同编写、共同演练	审批

每一行恰好只有一个主要负责方。第二行是你主导的地方：评测集成为共同的验收文档，SI 团队每次变更都运行它。这样一来，合同上的“完成”和业务结果上的“完成”就成了同一回事。

指出缺口，又不越界

85% 这个数字怎么说出来，和数字本身同样重要。周会上的对话可以这样进行。

你：“UAT 已全部通过，你们团队的集成工作做得很扎实。我们刚又跑了 200 份真实理赔，结果是 85%，业务目标是 95%。差距主要在 Agent 的行为上，这是我们这边的责任。”

SI 负责人：“那会影响我们的时间表吗？”

你：“集成部分不受影响。我只建议把这 200 份理赔加进你们的 CI，每次构建都报一个分数。我们修 Agent，你们马上就能看到结果。”

这段对话按顺序只做了三件事：肯定 SI 做得好的工作，认领缺口，再提出一个共同机制，也就是在 CI 中运行评测，而不是指责任何人。

从第一周开始的步骤

首先，要求阅读 SI 的 SOW，至少是范围和验收条款。用一句话写下按这份文件“完成”意味着什么，再与客户真正需要的结果对比。两句话之间的差距，就是你的工作计划。

接着，制定职责矩阵，请客户的技术负责人确认。客户点头之后，SI 就不会觉得是你自封了角色。

然后，用真实数据构建评测集，并提议把它作为共同的验收标准。dev.to 上发布的一份 FDE 实践手册建议，在写生产代码之前，先用一个可衡量的数字定义“能用”。如果质量真像 Forgepoint 所说的那样难以写进合同，那么一套可运行的评测集就是最接近质量条款的东西。

之后，每周与 SI 工程师开一次简短的平台交流会：讲平台的限制、故障时的行为以及即将到来的变更。这些知识只有你掌握，及早分享往往能为双方省下好几天的调试时间。

最后，从一开始就准备交接。同一份手册把 FDE 留下的东西描述为一个正在运行的系统，加上组织独立运维它的能力。

如果运维将由 SI 接手，就和他们一起编写运维手册，并演练一次故障：由 SI 工程师处理，你只在旁观察。

让 FDE 失去位置的三个陷阱

最常见的陷阱是把 SI 当成对手。在客户办公室里，两个团队一荣俱荣、一损俱损。带进会议室的，应该是“FDE 是顾问的补充”这一观点。

另一个陷阱是为了赶进度，悄悄替 SI 干活。进展缓慢时，人很容易急躁。但你替他们写的代码，到你离开项目那天，没人知道怎么运行。

最难察觉的陷阱，是把平台知识攥在自己手里，好显得不可或缺。你拿这份薪水，是为了让客户和 SI 能自己运行系统，而不是让他们永远离不开你。

如果你在面试技术厂商的 FDE 岗位，可以直接问：多久需要与集成商或咨询合作伙伴协作一次？答案会告诉你每天要用到哪些技能。

简历上要写具体：你把哪套评测集变成了共同的验收标准，SI 团队从什么时候开始独立运行系统。

下次启动会上有 SI 坐在你旁边，别再问自己来干什么。要问的是：合同是怎么定义“完成”的？