腾讯经销、字节驻场、Kimi借船：FDE成了大模型的新成本？

今年 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 工具搭建工作流，并沉淀标准化方案和模板。 内部团队最大的优势是反馈距离短。 工程师在客户现场发现检索效果不理想，可以直接将问题带回模型和平台团队；如果问题出在协作流程，也有机会从飞书产品侧寻找