腾讯、字节、Kimi，都开始往客户现场派人

文｜新立场

今年 3 月 6 日上午十点，深圳腾讯大厦楼下开始排队。人们带着电脑，等腾讯云工程师帮自己安装 OpenClaw，首批八十多人在十点开始排队，到十一点，数百个预约号已经发完。据腾讯方面提供的信息，当天有近千名开发者和 AI 爱好者来到现场。队伍里有退休航空工程师，还有小学四年级的学生。

OpenClaw 是开源软件。腾讯提供的 Lighthouse 云端部署方案，最快只需要五分钟。另一边，社交平台上已经有人做起代装生意。远程安装报价一般在 50 至 100 元，上门服务通常在数百元。软件可以免费获取，部署工具也越来越简单，人们却依然愿意为安装和配置付费。

六个月后，腾讯又做了一件相似的事。9 月 10 日，腾讯云推出 FDE 工程师认证，培训合作伙伴完成智能体项目的需求分析、方案设计、应用搭建、交付实施与安全合规。同一天，月之暗面宣布 Kimi 企业合作伙伴计划，与传统 IT 服务商、系统集成商共同培养前线部署工程师。

火山引擎的公开招聘页面上，也出现了几种不同的 FDE：有人负责 Agent 的开发部署，有人负责模型选型与推理优化，还有人专门进入客户现场，弄清楚客户究竟需要解决什么问题。

在大模型商业化中，一直有一段很难省掉的工作，即模型可以通过API提供给成千上万家企业，企业却各有自己的ERP、数据库、权限体系和业务流程。模型可以同时升级，客户的系统和组织却无法同步改变；模型卖出去以后，往往还需要有人跟进去，帮助它进入具体的工作环境。

因此，"FDE热"暴露的问题是，如果每增加一家客户，都要多派几名工程师，那大模型公司最终会变成什么样的公司？

同一个模型，接不进同一家公司

大模型最初看起来是一门接近标准化的软件生意。

把能力封装在 API 后面，制定统一的价格和调用方式，客户自行完成开发。模型升级一次，所有使用同一版本的客户都能受益。

但模型进入企业以后，工作通常没这么简单。假设一家企业希望 AI 帮忙审核合同，工程师真正开始实施时，首先要搞清楚合同存在哪里、谁可以读取、审核标准来自哪份制度、哪些部门有权修改，最后由谁批准。

模型即使准确发现合同中的异常条款，也未必有权访问原始文件，更无法自行决定企业内部的审批程序。换一家客户，这些问题往往要重新回答。

传统软件行业长期面对"企业越大，历史系统越多，定制需求越复杂，交付工作也越重"的问题。开发一套产品可能只需要做一次，部署到不同企业，却需要重复投入大量人力。

大模型没有消灭这些问题，只是把它们重新暴露了出来。

Palantir 很早就把解决这道难题的工作变成了一种产品开发方法。"human equivalent of backpropagation"——人类版的反向传播：工程师尽可能靠近客户实际面对的问题，与核心研发团队共同工作，再把现场不断产生的反馈送回平台，形成新的产品能力。

理解这套方法，可以从 Palantir 的三种角色开始。Echo 要找到客户真正需要解决的问题，协调业务人员和管理层；Delta 负责让技术方案运行起来，包括数据基础设施和实际应用；Dev 则与前两者协作，把已经验证的解决办法开发成可供更多客户使用的平台能力。

三种角色存在交叉，但形成了从现场发现问题到产品开发的协作链条。

火山引擎今年公开招聘的 FDE，体现了类似的分工。通用 FDE 要在客户环境里连接 API 和数据系统，从应用原型一直做到生产级 Agent，还要建设评估和可观测体系。算法方向的 FDE 则进一步负责模型选型、微调和推理优化，并把客户遇到的技术问题转化为方舟与 Seed 的产品需求。

火山引擎还专门招聘 FDE Echo，这个岗位的重点是访谈和观察客户，把模糊、零散的业务反馈整理成可以验证的产品机会，招聘要求甚至明确写入了至少五年的解决方案咨询工作经验。

这类岗位的出现，很大程度上是为了缩短客户需求在组织内部传递的距离。过去，一家企业说"月底对账太麻烦"，需求可能先由销售人员接收，再交给售前、产品经理和研发团队，几轮传递以后，研发收到的也许只剩下"需要增加一个财务接口"。

但客户遇到的问题，可能与接口本身毫无关系。是两个部门采用不同的数据口径，还是历史记录缺失？究竟应该增加接口、调整流程，还是让 AI 代替人工核对？工程师离客户太远，很难判断。

工程师离现场越远，对问题的判断越容易依赖二手描述。

FDE试图把工程师重新推到业务面前。参与实际流程、亲手搭建方案，再把反复出现的问题带回研发。如果这套机制能够正常运行，前一个项目留下来的经验，就有机会成为后一个项目直接调用的产品能力。

这是FDE和普通项目外包最容易拉开差距的地方。一个项目做完，只留下收入和一套客户专属代码，交付就只是交付；如果还能留下连接器、工作流模板、评测方法和新的平台能力，这笔人力成本才有可能被后续客户摊薄。

同时，这也是大模型公司开始重新重视FDE的商业原因。单纯提高Token调用量，只能说明企业使用了更多模型能力，模型真正进入客服、财务、研发、供应链等核心流程以后，企业还需要长期维护数据接口、权限规则、评估体系以及员工操作方式。

这些环节决定了 AI 能否成为企业日常运营的一部分，也决定了模型公司需要为每家客户投入多少交付资源。但紧接着，客户越多，需要进入现场的工程师也可能越多。一个模型可以服务十万家企业，一个工程师却无法同时完成十万家企业的部署。

因此，腾讯、字节、Kimi 和 OpenAI 走出了不同的路径。

腾讯、字节、Kimi，谁来承担交付成本？

9 月 10 日，腾讯云推出 FDE 认证，同时启动合作伙伴招募。腾讯把需求分析、方案设计、Agent搭建、交付实施和安全合规整理成培训与考核内容，依托ADP平台，帮助合作伙伴建立企业级智能体交付能力。官方给出的定位很明确，这套认证主要面向合作伙伴专业工程师和个人开发者。

这其实是 IBM、微软、SAP 都做过的事：把交付渠道化。

腾讯当前的选择，首先解决的是交付半径。ADP不需要为每一家企业配备自己的工程师，合作伙伴越多，可以进入的行业和客户也越多。对拥有庞大云生态的腾讯来说，这套体系比完全依靠自有FDE扩张更符合既有的商业基础。

但渠道可以复制工程师，项目经验并不会自动复制。

一家合作伙伴为某家银行开发了一套特殊的权限流程，另一家伙伴服务第二家银行时，可能重新碰到相似的问题，如果项目经验长期沉淀在不同服务商的代码库和实施团队里，平台能够快速增加的主要还是交付人数。

腾讯接下来需要把FDE生态做成一套"越交付越省力"的系统。

合作伙伴在现场重复遇到的问题能否稳定进入ADP，ADP更新后的能力能否再回到整个伙伴体系，决定了这张交付网络最后沉淀下来的是人力规模，还是产品能力。

字节选择了一条更贴近内部研发的路径。

字节则公开招聘了一组分工不同的 FDE，火山引擎的通用、算法与 Echo 岗位，分别覆盖应用工程、模型优化和客户需求发现。飞书商业化也在招聘 FDE，让工程师进入客户工作场景，使用飞书 AI 工具搭建工作流，并沉淀标准化方案和模板。

内部团队最大的优势是反馈距离短。工程师在客户现场发现检索效果不理想，可以直接将问题带回模型和平台团队；如果问题出在协作流程，也有机会从飞书产品侧寻找解决办法，客户现场与产品研发之间少隔一层，信息损耗自然更小。

但这条路同时意味着，更多交付成本需要留在自己的组织里。

做完第一个银行项目，第二家银行的工作量能减少多少；进入汽车和零售以后，银行项目积累下来的经验还能复用多少。这些问题最终都会体现到FDE的人效上。

对自建FDE团队的公司来说，工程师数量增长本身没有太大意义。更重要的数据，是相似项目所需的人天有没有持续下降。

如果项目越来越多，FDE团队也按照相近的比例扩张，业务规模扩大了，组织同样会越来越重。只有现场经验持续变成标准组件、平台能力和行业模板，自建团队离研发更近的优势才能真正兑现。

Kimi干脆跳过了这一步，把合作伙伴放在了企业交付计划的核心位置。9 月 10 日，月之暗面宣布与华胜天成、金山云、亚康股份、亚信科技、中软国际等企业合作，共同培养 FDE 队伍。Kimi 提供模型、Hosted Agents 运行底座和工程方法，合作伙伴负责发挥已有的行业知识和客户服务能力，共同完成项目交付。

Kimi 可以借助它们已经建立的客户关系和交付队伍，进入自己尚未深耕的行业。但在这种合作中，一个 Agent 为什么在客户现场运行不顺利，究竟是模型的问题、工作流设计的问题，还是历史系统的问题，最先了解情况的往往是合作伙伴。客户现场的信息怎样回到 Kimi，就成为这套合作模式中的一个关键环节。

今年 1 月，医疗 AI 初创公司 Lamar Health 的 FDE Hayden Krush 在接受 FDE Hub 采访时，谈起了自己的日常工作。他负责将 AI 接入专科药房的保险事前授权流程。有时，他要连续一周写代码，完成客户的初始系统集成；有时，他一天都在回复邮件，处理客户不断出现的新问题。

工作中很重要的一部分，是弄清楚客户到底希望系统如何处理那些极其具体的例外。比如，两名患者的姓名和出生日期完全相同，系统究竟应该选择谁？Hayden 所在的团队选择将决定权留给客户，不让 AI 自行判断。此外，他发现越大的功能通常越需要针对客户做调整，一些来自客户的小建议，比如修改一个界面，却可能很快让所有客户受益。

这也是 Kimi 需要面对的，Kimi 可以借助服务商的人进入更多企业。至于这些人在现场学到的东西，有多少最终能够进入 Kimi 的产品，仍需要后续项目来检验。

OpenAI 还是经典的力大砖飞，干脆为这件事单独搭了一家公司。5 月 11 日，OpenAI 宣布成立由自己持有多数股权并控制的 Deployment Company，计划投入超过 40 亿美元的初始资金。它同时宣布拟收购 AI 咨询与工程公司 Tomoro，交易完成后将为新公司带来约 150 名 FDE 和部署专家。

它采用独立公司的组织形式，同时与 OpenAI 的研究、产品和内部部署团队保持连接。这样既可以建立专门面向企业交付的组织，也保留现场经验进入模型与产品研发的路径。

超过40亿美元的投入本身，就足以说明企业AI现在的成本结构：模型研发依旧烧钱，把模型真正放进一家大型企业，同样是一门需要重投入的生意。

OpenAI没有把这一段全部留给埃森哲、IBM或者其他系统集成商，它选择自己控制一家专门的部署公司。它既希望拥有企业现场，又不希望庞大的项目交付完全进入基础模型公司的主体组织。

这其实也是FDE热潮里很有意思的一幕：越靠近企业核心流程，大模型厂商越需要补上过去属于企业软件、咨询公司和系统集成商的能力。

腾讯把其中一部分能力交给生态，字节更多留在内部，Kimi借助传统IT服务商，OpenAI干脆成立一家独立公司。

组织形式各不相同，最终都绕不开三笔账：交付的人由谁来承担，客户现场的信息由谁掌握，做完一个项目以后，有多少东西可以直接留给下一次。

这三笔账，也决定FDE最后会成为AI公司的规模杠杆，还是一个随收入一起膨胀的成本中心。

Palantir已经开始让软件接手一部分过去由现场工程师完成的工作。今年，AI FDE逐渐获得更多Foundry操作能力，可以处理数据、代码、评估和平台资源。9月8日，Palantir进一步推出AIP Evolve，让多个AI FDE Agent协同优化已经运行的AI系统。用户可以指定成本、延迟、评估效果等目标，并设置测试数据和修改边界，再由Agent提出改进方案。

Palantir自己在介绍AIP Evolve时说了一句话：You can't scale what only humans can fix。（只靠人才能修好的系统，很难真正扩大规模）

这句话也适用于今天的FDE。腾讯今年发出多少张认证，字节招了多少工程师，Kimi签下多少合作伙伴，都只是早期数字。企业AI真正进入规模化阶段以后，项目数量增长并不足以说明模式跑通。

第一个银行项目需要十个人做三个月，第二个项目如果仍然需要十个人做三个月，公司的收入虽然增加了，人力成本也会跟着上升；如果第二个项目只需要五个人，一个月就能完成；再往后，数据接口、权限规则、行业评测和常用工作流都已经成为平台里的标准能力，这门生意才开始表现出软件应有的复制能力。

FDE最有价值的地方，就是能把一次昂贵的现场经验变成下一次可以直接调用的东西。

沿着这条路继续走，未来一个FDE从银行完成项目回来，不必再为下一家银行从头编写数据接口、配置权限、处理那些似曾相识的异常。

上一个项目踩过的坑已经写进产品，下一次，工程师仍然要走进客户现场，但可以少做很多已经做过的事。

对今天的大模型公司来说，这大概也是FDE这笔账最终要算清楚的地方：客户可以一家一家拿下，交付不能永远一家一家从头再来。

*题图及文中配图来源于网络。