Gartner 于 2026 年 9 月 29 日预测：到 2028 年 70% 的企业会弃用厂商用「前置部署」工程搭出的智能体 AI，并给出三段合约框架。 这条预测落在「前置部署」Forward Deployed Engineer（FDE）的合约段与退出段，而不是模型能力段。Gartner 把风险定位在交付结构而非技术，这恰好是「前置部署」Forward Deployed Engineer（FDE）每天处理的那一段：范围、激励、治理、所有权与退出。对在客户现场做交付的「前置部署」Forward Deployed Engineer（FDE）来说，这份材料的价值是把「怎么签、怎么交、怎么走」拆成了可以直接写进合同的条款。 这份材料是 Gartner, Inc. 在 2026 年 9 月 29 日从康涅狄格州斯坦福德（Stamford, Conn.）发出的官方新闻稿，标题即结论：到 2028 年，70% 的企业会弃用由厂商「前置部署」工程搭出的智能体 AI。署名分析师是 Gartner 高级总监分析师（Sr Director Analyst）Mukul Saha。完整方法论不在公开页面，而在给客户的付费文档《The Forward-Deployed Engineering Playbook》里，文档编号 860278。 新闻稿先给了一个定义：厂商「前置部署」（vendor FDE）指的是厂商工程师直接与客户一起工作、构建并部署解决方案的模式。这个定义把讨论范围限定在「厂商替客户建」这一类交付，而不是企业内部自建的工程团队，也不是只卖许可或只卖 API 的采购。 还有一句判断被放在框架之前单独成句：FDE engagements often fail structurally before they fail technically，也就是「前置部署」交付往往先在结构上失败、再在技术上失败。它同时划出了责任顺序：范围、激励、治理、所有权这四件事在签约时就能定，一旦定错，后面靠技术手段补不回来。 第一条预测到 2028 年 70% 的企业会放弃这类系统。Gartner 给的两个原因是成本飙升，以及企业自身无法演进这套系统，原文用的是 trapped by soaring costs and unable to evolve it on their own，也就是「被飙升的成本困住、又无法自行演进」。注意这里的重点不是系统不能跑，而是企业跑不动它。 这条预测的实际含义对「前置部署」Forward Deployed Engineer（FDE）是直接的：如果交付的产物只有厂商团队能改，那么交付的终点就是成本曲线的拐点。Gartner 把 70% 的量级放在 2028 年，意味着它认为这不是个别失败案例，而是交付模式的默认走向。 第二条预测是到 2028 年，能把客户重复出现的需求转化成厂商核心产品能力的「前置部署」交付不足 20%。Gartner 由此提出 FDE washing 这个概念，新闻稿的原文是 where consulting services are marketed as FDE，也就是把咨询服务当成 FDE 来卖。这一条比 70% 更值得交付方警惕，因为它衡量的是交付有没有形成「知识沉淀」。 「前置部署洗白」在新闻稿里的具体描述是：很多供应商把 implementation、专业服务、解决方案工程或 AI 咨询都贴上 forward deployed 这个标签，有的经过认真设计，有的只是因为这个说法听起来更战略。Saha 的原话是，有些供应商收了溢价费用，却没有与之匹配的「交付深度」、项目管理或「变革管理」成熟度。 后果被 Gartner 拆成三步传导。第一步，客户早期看到更快的进展。第二步，客户没有建起自己的「独立能力」。第三步，客户为「范围一旦清晰之后完全可以交给传统服务或伙伴模式、成本更低也更可预期」的工作继续支付溢价。这里隐含的判断标准是范围是否清晰，而不是供应商是否知名。 Saha 的两句原话可以当成这套框架的定调。第一句是 FDE success starts with getting the engagement structure right, from scope and incentives to governance, ownership, and exit，意思是成功的起点是合约结构，覆盖范围、激励、治理、所有权与退出五个维度。第二句是 The best-scoped FDE engagements have clear guidelines on governance, business value delivery, IP ownership, project co-ownership, knowledge transfer, and an exit strategy from day one，也就是范围讲得最清楚的交付，从第一天起就写明了六件事。 第二句里的六件事可以直接抄成合同清单：治理、业务价值交付、知识产权归属、项目共有权、知识转移、退出策略。Gartner 的关键限定词是 from day one，即签约当天生效，而不是交付收尾时补签。这六项也是判断一份合约是不是真「前置部署」合约的最小集合。 三段框架的第一段是签约前（Before Signing）。Gartner 给的适用范围是三类问题：需要深度产品专业知识的问题、需要快速适配的问题、以及厂商技术与客户运行环境需要紧耦合的问题。三个条件都不满足时，Gartner 的建议是不要用「前置部署」，改用传统服务或伙伴模式。 同一段里还有两条合约动作。第一条是任命一位「执行发起人」对业务结果负责，而不是只对实施预算负责，原文是 accountable for business outcomes, not simply the implementation budget。第二条是把关键「合约要求」写进合同，Gartner 明确点出这些要求超出采购部门通常管的范围，包括交付物、知识转移、知识产权、交接或退出责任四项。 第二段是交付中（During the Engagement）。做法是把「前置部署」工程师与客户内部的领域专家、工程师和终端用户编在同一个队伍里，让关键知识在过程中转移，而不是交付完成后再安排培训。Gartner 写的目的是让解决方案反映工作实际上是怎么完成的。 同一段还要求建立「迭代业务验证」的节奏，每个增量都要回答四个问题。这四个问题是：决策权归谁、自治与人机监督之间的平衡点在哪里、置信度与例外如何沟通、以及维持用户信任与问责的「治理机制」怎么建。Gartner 明确说评估对象不只是技术表现，还包括把 AI 规模化所需要的运行模型。 第二段的原话值得整段抄下来对照。Establish a cadence of iterative business validation that evaluates not only technical performance but also the operating model required to scale AI responsibly；Use each increment to define decision rights, determine the appropriate balance between autonomy and human oversight, clarify how confidence and exceptions are communicated and build the governance mechanisms that sustain user trust and accountability。翻译过来就是：每一次交付增量都要顺带产出决策权、监督边界、例外沟通与治理机制四项资产。 第三段是退出并证明独立（Exit and Prove Independence）。Gartner 的表述很硬：执行一开始就定好的「退出计划」，而不是因为内部团队还没准备好就延长合约。验收标准也被改写了：成功不以实施完成为准，而以企业能否独立管理、优化和扩展这套技术为准，其中包括在业务流程、优先级和风险画像变化时调整人机决策模型。 第三段同样有原话，且是这套框架里唯一一条验收定义。Ensure the organization develops the capabilities, governance, and operational ownership required to independently sustain and evolve the solution over time；Success is measured not by implementation completion, but by the enterprise's ability to manage, optimize, and scale the technology, including adapting human-AI decision models as business processes, priorities, and risk profiles evolve。这段话把验收主体从供应商交付物换成了企业的运营所有权，这是整份材料里最难被合同绕过的一条。 Gartner 单独用一个小节强调，「前置部署」必须被视为一种交付模式，而不是一个采购品类。它承认这个模式底层的做法在传统企业软件里并不新鲜：把技术上强、懂产品的人放在客户身边。Gartner 说新的部分只是围绕它的热度强度。 这份预测出现在一个正在扩编的市场上。Investor's Business Daily 在 2026 年 9 月 29 日的报道里列出已经采用「前置部署」打法的公司：把工程师嵌入客户环境这套蓝图最早来自 Palantir，现在 OpenAI、Anthropic、ServiceNow、Salesforce、Databricks 与 Microsoft 都在用。IBD 同时给出 Palantir 2026 年以来的股价涨幅为 5%，此前一度下跌 30%，并说明 Gartner 没有点名任何一家具体厂商。 把两个数字放在一起看，可以读出 Gartner 对商业模式的判断。70% 说的是成本走向，20% 说的是资产沉淀比例，两者相乘意味着大部分「前置部署」收入不会复利成产品能力，而要靠不断接新的现场项目来续期——这正是成本会被形容为 soaring 的结构原因。需要说明，这层推演是本文的解读，Gartner 新闻稿只给出两个数字与两个原因，没有写出这条推理链。 对正在选型或正在签合约的一方，这份材料的价值在于它把风险从模型行不行换成了合同怎么写。70% 与 20% 都是预测值而不是测量值，但它对两边的动作指向是清晰的：交付方要把能力沉淀进产品，采购方要把「退出策略」写进合约。 谁该行动分三类。第一类是正在签或准备续签「前置部署」交付合同的软件工程负责人。第二类是有厂商驻场工程师、需要负责验收的业务方。第三类是负责「合约条款」的法务与采购。只买 IaaS、只买许可、或完全由内部团队自建的项目不适用这套框架。 具体动作按五步走，每一步都有可检查的产出物。第一步是筛：对每个候选需求问三遍，是否需要深度产品专业知识、是否需要快速适配、是否与运行环境紧耦合，三问皆否就改用传统服务或伙伴模式，不要用「前置部署」这个名字包装。第二步是定人：在合约里写明一位「执行发起人」，其考核口径是业务结果而不是实施预算。 第三步是写条款：把治理、业务价值交付、知识产权归属、项目共有权、知识转移、退出策略六项逐条落成合约文字，并单独列明「交付物清单」、知识转移的验收方式、交接或退出责任。第四步是设节奏：约定「迭代业务验证」的频率与参与人，每轮输出决策权、人机监督边界、置信度与例外的沟通方式、治理机制四项记录。第五步是验收独立性：以客户团队能否独立管理、优化、扩展、以及能否「独立运维」为准，而不是以系统上线为准。 退出方式必须写死在合同里，因为技术侧没有回滚路径。Gartner 没有给出任何技术回滚机制，它给的唯一机制是签约时约定好的「退出计划」，并且在第三阶段按原计划执行、不因内部能力不足而延期。已经在依赖单一供应商的组织，能立刻做的是把六项条款补进下一次续签的合约，而不是等到合同到期才谈。 适用条件需要写清楚，避免把结论套错场景。本文结论成立的前提是「前置部署」属于厂商工程师驻客户现场、为客户环境构建并部署解决方案的模式。自有团队主导、厂商只提供许可或 API 的项目不在讨论范围内。Gartner 的三段框架针对的是智能体 AI 这类需要持续演进的系统，一次性集成项目套用会明显过重。 局限要先讲最关键的一条：Gartner 没有公开这组预测的样本量、统计口径与推导方法。70% 与 20% 是预测而不是测量，新闻稿里也没有给出当前「前置部署」交付的失败率或延期率基线，所以无法判断 70% 是从当前失败率外推，还是从成本曲线外推。完整方法论在付费文档 860278 里，公开页面拿不到。 其次，Gartner 没有按行业、企业规模或地域拆分这组数字。对 air-gapped 环境、以及需要 FedRAMP、ITAR 或 CMMC 合规的交付场景，公开材料没有单独讨论，而这类场景恰恰是退出最难的一类：数据与系统已经落在客户场地，迁移成本与合规审计成本都不在 Gartner 的公开口径里。 第三，FDE washing 只有描述性定义，没有可量化的识别指标。Gartner 没有给出判断一家供应商是否属于「前置部署洗白」的阈值，比如驻场工程师的时长下限、知识转移的验收标准、或者需求回流到核心产品的比例门槛，因此采购方拿不到一把现成的尺子，只能按六项条款自行构造检查表。 第四，发布方本身有商业利益。这份预测随 Gartner IT Symposium/Xpo 的议程发布，该会议的场次包括 2026 年 10 月 19 日至 22 日奥兰多、11 月 4 日至 6 日横滨、11 月 9 日至 12 日巴塞罗那、11 月 16 日至 18 日科钦，而完整方法论放在付费文档里。引用这类预测时，应把它当成一份立场明确的行业判断，而不是独立测量结果。 还有三类对象没有被覆盖，需要读者自行补齐。第一类是中文市场与本土交付商的驻场模式，公开材料没有纳入。第二类是开源替代路径，即企业用开源编排框架自建交付能力是否更便宜，Gartner 没有做比较。第三类是交付失败后的资产归属与数据处置流程，新闻稿只提到知识产权归属要写进合同，没有给出具体的处置步骤。 给两类读者的可执行结论不一样。交付方立刻要做的是把重复出现的客户需求登记成产品 backlog 条目，并把回流比例做成可汇报的指标，因为 Gartner 的 20% 门槛正是指向这一项。采购方立刻要做的是在合约里补上知识转移的验收方式与退出责任，因为这两项一旦缺位，第三阶段的独立性验收就没有依据。 签约与退出自检清单，逐条勾选，每一条都对应上面某一段的结论。 - FDE（前置部署 Forward Deployed Engineer）：确认合约里写了六项条款：治理、业务价值交付、知识产权归属、项目共有权、知识转移、退出策略。 - FDE（前置部署 Forward Deployed Engineer）：确认六项条款的生效时点是签约当天，而不是交付收尾补签。 - FDE（前置部署 Forward Deployed Engineer）：按三问筛子决定是否用「前置部署」：深度产品专业知识、快速适配、运行环境紧耦合。 - FDE（前置部署 Forward Deployed Engineer）：三问皆否时改用传统服务或伙伴模式，不要用「前置部署」包装咨询服务。 - FDE（前置部署 Forward Deployed Engineer）：在合约里指定一位「执行发起人」，考核口径写明是业务结果。 - FDE（前置部署 Forward Deployed Engineer）：确认「执行发起人」不只对实施预算负责这一条写进文字。 - FDE（前置部署 Forward Deployed Engineer）：把「交付物清单」拆成可验收的条目。 - FDE（前置部署 Forward Deployed Engineer）：把知识转移的验收方式写成可检查的动作。 - FDE（前置部署 Forward Deployed Engineer）：把知识产权归属与项目共有权分成两条写。 - FDE（前置部署 Forward Deployed Engineer）：把交接清单与退出责任写进签约文件。 - FDE（前置部署 Forward Deployed Engineer）：约定「迭代业务验证」的频率、参与人与输出格式。 - FDE（前置部署 Forward Deployed Engineer）：每轮「业务验证」输出「决策权」归属的书面记录。 - FDE（前置部署 Forward Deployed Engineer）：每轮「业务验证」输出「人机监督」的边界说明。 - FDE（前置部署 Forward Deployed Engineer）：每轮「业务验证」输出置信度与例外的沟通方式。 - FDE（前置部署 Forward Deployed Engineer）：每轮「业务验证」更新「治理机制」的版本并归档。 - FDE（前置部署 Forward Deployed Engineer）：把「前置部署」工程师与客户领域专家编在同一队伍。 - FDE（前置部署 Forward Deployed Engineer）：让「前置部署」工程师直接接触终端用户，而不只对接 IT。 - FDE（前置部署 Forward Deployed Engineer）：把驻场时长与轮换计划写进交付计划。 - FDE（前置部署 Forward Deployed Engineer）：设定需求回流指标：重复出现的需求转为产品能力的条目数。 - FDE（前置部署 Forward Deployed Engineer）：用 20% 这条门槛自查：有多少重复需求真的进了厂商核心产品。 - FDE（前置部署 Forward Deployed Engineer）：识别「前置部署洗白」信号：供应商是否有「交付深度」与项目管理编制。 - FDE（前置部署 Forward Deployed Engineer）：核对溢价是否对应「交付深度」、项目管理与「变革管理」成熟度。 - FDE（前置部署 Forward Deployed Engineer）：不为听起来更战略的标签支付溢价。 - FDE（前置部署 Forward Deployed Engineer）：第三阶段按原计划执行退出，不因内部没准备好而延期。 - FDE（前置部署 Forward Deployed Engineer）：用能否独立管理做第一项验收。 - FDE（前置部署 Forward Deployed Engineer）：用能否独立优化做第二项验收。 - FDE（前置部署 Forward Deployed Engineer）：用能否独立扩展做第三项验收。 - FDE（前置部署 Forward Deployed Engineer）：约定业务流程与风险画像变化时的人机决策模型复审节奏。 - FDE（前置部署 Forward Deployed Engineer）：对 air-gapped 与合规场景单独评估退出成本，公开材料未覆盖。 - FDE（前置部署 Forward Deployed Engineer）：把 70% 与 20% 当作预测而非测量，交叉验证后再写进决策文件。 原始来源： - https://www.gartner.com/en/newsroom/press-releases/2026-09-29-gartner-predicts-70-percent-of-enterprises-will-abandon-agentic-ai-built-by-vendor-forward-deployed-engineering-by-2028 - https://www.gartner.com/document-reader/document/code/860278/preview - https://www.investors.com/news/technology/palantir-stock-ai-sales-strategy-fde-gartner-warning