供应商撤场之后，智能体还改得动吗

周五下午，一家制造企业的运营负责人想改一条规则：超过两万元的赔付要两个人签字。这条规则是智能体上线那年写进流程的，改起来本该是半小时的事。IT 请他等一等，因为负责这块的供应商三个月前撤场了，留下的代码没有对应的测试，改完没人知道会不会把其他判断带歪。他最后的选择是不改。

这种事不会出现在任何一份年度报告里。它表现为一个流程参数冻在某个季度，业务绕开系统另外开了个表格。真正的变化要等到一两年后才显形：预算里还留着这个智能体，但它已经不参与任何决策了。

这条规则为什么改不动

改不动跟模型能力没关系，也跟代码写得好不好关系不大。一个智能体的行为由四样东西决定：模型、提示词与工具、它能触碰的权限，以及一套关于什么叫判断正确的标准。

前三样供应商都会交出来，因为它们有形。配置在仓库里，权限在表里，模型在合同里写着名字。第四样通常不交，因为它不是文件。它是驻场工程师在这门业务里待了八个月之后形成的经验：哪些边界情况应该保守，哪些错误代价大可以放宽，客户嘴上说的规则和实际执行的规则差在哪。这些判断散落在他们做过的每一次评审、每一次解释、每一次当场改口径里。

结果是一个不对称的状态。你拿到了系统，没拿到判断系统对错的能力。第二天业务提一个新要求，你有两条路：改，然后无法证明没改坏；或者不改。绝大多数组织选不改，因为不改不会有人在两周后追责。

这就是弃用的真实过程：一堆被推迟的改动慢慢累积，最后被贴上弃用的名字。Gartner 把原因写成成本飙升和无法自行演进两条，其实这是同一条的两个刻度：头一年表现为改一次报一次价，第二年表现为预算留着但没人动它。

七成这个数字的读法

2026 年 9 月 29 日，Gartner 发布了一份预测：到 2028 年，70% 的企业会放弃由供应商驻场工程建成的智能体，受困于成本上升和自身无法演进。同一份材料里还有第二个数字，比第一个更能说明问题：到 2028 年，不到 20% 的驻场工程会把客户的重复需求沉淀成供应商核心产品的能力。

第二个数字解释第一个数字。驻场工程本该是一条双行道：客户拿到能用的系统，供应商拿到可以复用的能力。如果不到五分之一的项目走通了回程，那么绝大多数项目在供应商内部也是一次性的，下一次同类需求从零开始报价。客户看到的成本上升，正是这个结构的必然结果。

Gartner 还给这个现象起了个名字，叫 FDE 洗白，指把实施服务、解决方案工程或 AI 咨询贴上驻场工程的标签来卖，收费更高，交付深度不够。分析师的原话是，有些供应商这么做是认真想过，有些只是因为这个说法听起来更战略。

这份材料的性质要说清楚：它是分析机构的预测，70% 和 20% 都不该被当成已经发生的事实引用。但它描述的三阶段结构值得当成一份检查表用，因为那部分是可执行的：签约前定范围与激励，交付中把客户的人嵌进去，退出时按第一天定的计划执行，而不是因为内部还没准备好就延期。

三种交付物，只有一种是资产

把交付物拆开看，差别就清楚了。

代码是可读的，但读代码读不出为什么某个判断是对的。它记录的是当时做了什么，不记录当时为什么这么定。换一个工程师接手，他能做的事只有照原样跑。

提示词和工具是可改的，改完也算快。问题在于改完没有人能证明别的判断没被带坏。智能体的特点是一次改动会同时影响几十个场景，而人只能同时想到三四个。

评测集是唯一能在供应商走后继续回答改了会不会坏的东西。它由一条条真实的判断记录组成，每条至少四个字段：当时的输入、系统当时给出的输出、人最终采用的版本、这属于哪一类错误。有了这四个字段，改动才有可能被验证；缺任何一个，半年后这条记录就失去意义，因为你分不清是人改了主意还是系统改坏了。

关键在那四个字：真实的判断。从设计文档里推导出来的测试用例只覆盖你想到的失败，而真正会出问题的是你没想到的那部分。评测集必须长在客户的系统里，用客户的流量和历史记录喂养，否则它只是一份演示材料。

还有一个组织问题要提前定：这份集合由谁维护。放在供应商仓库里，退出那天它跟着走；交给一个不懂业务的 IT 团队，半年后没人知道某条记录为什么采用那个版本。可行的做法是业务侧指定一名所有者，工程侧指定一名维护者，每季度一起过一遍新增样本，把新增的错误类型写进分类表。人是这个资产的一部分，这一条在合同里写不出来。

三个提前信号

弃用是缓慢发生的，所以它有前兆。三个信号出现任意两个，通常意味着一到两个季度后这个系统就会停止参与决策。

第一个信号是改动周期变长。上线后的前三个月业务提需求，一周内能改；半年后同样的需求要走变更单，两周；一年后需求单的回复是先评估。周期变长的原因通常不在技术复杂，在于每次评估都要外部参与，而外部参与的报价又需要走采购。

第二个信号是业务开始绕开系统。有人在系统外开了表格，把例外情况记在里面，因为改系统太慢。这种绕行一开始是临时的，三个月后它变成了真正的流程，系统只剩下留痕的作用。这时候系统的失败率看起来还会变好，因为没有人在用它处理难的那部分。

第三个信号出现在预算表上：口径从项目费变成年度维护费，同时多出一行评估或咨询的科目。这一行说明组织已经在为改不动付钱了，只是还没给它命名。

自己重做一个为什么通常更贵

听到这里，一个自然的反应是自己重做一遍，把控制权拿回来。这条路成立，但代价常常被低估，代价不在写代码。

重做一个智能体的工程成本，今天是可控的：模型接口、编排框架、权限层都有现成的东西。真正贵的是把判断标准重新积累一遍，而积累只能靠时间。原来那套标准在八个月的运营里，是用几千次真实交互磨出来的，涉及客户的业务规则、监管口径、历史遗留做法。重做意味着重新经历一遍这些交互，中间难免出错，而错在客户侧是有价格标签的。

所以重做要跟旧系统维护费加上重建期间的风险敞口相比，只看维护费会把账算反。这个账多数时候算下来，接手比重建便宜，前提是旧系统里还有能被接手的东西。反过来说，如果那份判断记录从来没留下，重建就成了唯一选项，这也是为什么交接这件事必须在项目启动时定，不能在结束时定。

合同里值得争的三条

如果这套判断成立，驻场工程合同的重心要往三个地方挪。这三条都不新，难点在于有没有人真的把它写进验收动作。

第一条，里程碑的验收不是演示，而是一次交接测试。客户团队指定两个人，在不联系供应商的前提下，往评测集里加一条新规则，跑一遍，并解释结果为什么通过或失败。做不到，这个里程碑不结算。这个动作五十分钟能做完，它比任何一份验收报告都可靠，因为它检验的是能力有没有转移，而不是功能有没有实现。

第二条，知识产权的范围要写到判断标准上，而不只是代码。评测集、错误分类法、阈值设定，这三样归谁，要在签约时写清楚。合同里只写代码归属，等于把最贵的那部分留在了供应商的服务器上。

第三条，退出计划在签约当天写，不在续约谈判时写。这跟 Gartner 的建议一致：退出要按第一天定的执行。理由很实际，续约谈判时双方的信息已经不对称，客户越急，条款越差。

还有一条是内部指标，不写进合同但比合同更有用：每个季度数一数，客户团队在没有供应商陪同的情况下独立完成了多少次改动。这个数字如果在下降，交付就在退化，哪怕功能清单一直按时完成。

什么时候不该走驻场工程

反过来说清楚，这套逻辑不适用于所有情况，否则它就变成了推销。

需求通用的时候不该用。标准的 CRM 对接、标准的报表迁移、标准的数据清洗，传统实施商更便宜，结果也更可预测，因为它已经做过很多遍。驻场工程的溢价买的是陌生问题的快速适应，用在熟悉问题上就是浪费。

错误可以立刻回滚的一次性工具，也不值得走完整套交接。内部知识搜索、会议纪要整理这类东西，坏了重跑一次就行，为它建立评测集和维护流程，成本高于风险。

还有一个前提最容易被跳过：组织里得有人能接手。如果没有两个懂业务又看得懂系统的人，交接只是把同一个问题推迟一个季度，评测集会被做出来，然后没人读。这种情况下先补人比先上系统有效。

我们的判断

我们的判断是，企业买驻场工程买错了东西。它以为自己在买一个能跑的智能体，实际上唯一值得买的是能不能改这项能力。智能体会随业务变化而过期，能改的能力不会。所以交付的验收标准应该是可修改性，而不是功能完成度。

这个判断可以立刻检验，成本不到一天。第一步，把现有智能体替人做的判断列出来，通常不会超过二十条：放行还是拦截、归类还是转人工、补全还是留空。第二步，为每一类判断从历史记录里抽二十条真实输入，做成一个不超过一百条的固定集合。第三步，指定两个人，让他们独立跑一遍这个集合，记录通过率，并且不许打电话问原来的供应商。

这三步做完，你会得到两个结果之一。要么你发现自己的团队能接住，那这个智能体是资产；要么你发现没人答得上来某一类判断为什么这样定，那类判断就是供应商撤场后第一个出事的地方。第二种结果现在知道，比明年三月知道便宜得多。

留给买家的问题是：如果你的供应商下周一撤场，你团队里谁能回答改这条规则会不会弄坏别的判断？能说出名字，交接就是真交了；说不出来，交接还没开始，剩下的只是功能清单。

参考来源

Gartner, Gartner Predicts 70% of Enterprises Will Abandon Agentic AI Built by Vendor Forward-Deployed Engineering by 2028, 2026-09-29（预测，非统计；含三阶段框架、不到 20% 的沉淀比例、FDE 洗白定义）

Gartner, The Forward-Deployed Engineering Playbook（研究文档，需客户权限）