文 | 字母AI

企业采购Agent，门槛正在肉眼可见地降低。

OpenAI、Anthropic、Google和微软在争夺大客户，Salesforce、ServiceNow、Workday等SaaS厂商则忙着把Agent塞进每一个功能页面。

买Agent这件事，本身已不再是难题。可当企业真刀真枪去部署时，麻烦接踵而至：

买下Agent，不等于让Agent真正干活。

美国抵押贷款巨头CMG Financial就撞上了这堵墙。其首席战略官Paul Akinmade曾在Salesforce年度大会上放话，公司下一阶段要让100个Agent上线运行。现实却给了他一记闷棍。

此前，CMG已将部分软件开发迁移至Claude Code，团队展现了对最新AI工具的快速上手能力。但当试图让Agent深入Salesforce、介入真实业务流程时，进度突然卡壳。

他们很快看清一个事实：Agent能写代码、调API，却读不懂一家企业多年沉淀的数据、权限体系和业务逻辑。

这类困境并非孤例。猎头公司Christian & Timbers（C&T）的一项行业调研显示，美国目前真正具备将AI系统部署进企业、并能帮客户拿到量化回报的前线部署工程师（FDE），总数仅约2000人。

随着企业从“试探性使用AI”转向“规模化部署”，大型咨询与服务公司正迅速扩充此类团队。

AI产业由此出现一个略带讽刺的转折：企业并不缺Agent，缺的是那些愿意替它收拾旧系统残局的人。

最终帮CMG理清头绪的，是一家名为June的创业公司。

**100个Agent，困在Salesforce里**

大模型公司演示Agent时，往往给的是一个无菌环境。

数据已清洗完毕，接口已打通，任务边界清晰，权限预设妥当。Agent只需在这条平整跑道上证明速度即可。

但现实中的企业系统，鲜有如此整洁。

一家运营十几年的公司，通常同时混用Salesforce、ServiceNow、Workday、Databricks以及一堆自建系统。同一个客户可能躺在四个数据库里，拥有四个编号、三种状态和两个负责人。系统间还残留着历次组织调整、产品改版和管理层更迭留下的痕迹。

这些痕迹未必是技术故障，更多是部门间的认知差异：销售部按“是否产生商机”界定活跃客户，财务部看“是否回款”，客服认为关系终止，合规系统却要求保留档案。

每个字段背后，都牵扯着部门利益、责任边界和历史遗留问题。

在传统软件时代，老员工的经验能暂时消化这些矛盾。他们知道某个名为“客户状态”的字段其实两年未更新；财务人员清楚导出报表后需手动修正三列；销售经理明白系统里关闭的项目仍有挽回余地。

但Agent没有这种默契。它只能机械读取字段，严格执行授权指令。

过去靠人类经验勉强维持的系统漏洞，在Agent面前成了必须解决的大麻烦。错误的客户状态可能导致发送不合时宜的营销邮件，错误的贷款状态则可能触发风控、合规甚至法律责任。对Agent而言，这就是一座庞大且混乱的“屎山代码”。

这正是CMG面临的障碍。

CMG Financial并非AI新手。作为美国抵押贷款公司，近年来一直在探索AI引入业务流程。公司已启用Claude Code辅助软件开发，证明了工程团队对最新AI工具的适应力。

在Salesforce生态中，CMG希望扩大AI应用范围。

此前，首席战略官Paul Akinmade在Salesforce年度大会上立下目标：下次参会时，公司希望已有100个Agent投入运行。

但当Agent真正嵌入企业流程，CMG发现事情远比想象复杂。

迁移代码到Claude Code相对轻松，因为代码边界清晰，错误可通过测试、审核和回滚控制；让Agent进入Salesforce则不同，它面对的是公司多年经营留下的数字沉积物。

在此情境下，Agent部署不再是纯技术问题，它迫使企业回答一系列长期回避的问题：哪套数据算真？谁有权修改？谁为错误买单？哪些历史流程该废弃？

为了让Agent真正融入工作流，CMG不得不引入架构师、咨询顾问和前线部署工程师（FDE）来梳理现有系统。

几周过去，项目进展仍未达预期。

直到CMG接触到了June这家创业公司。

June创始人Efrat Rapoport将CMG的痛点概括为：创建Agent模板不难，难的是处理其下的混乱。

June的方案是先给企业系统做一张“病历”。它会扫描现有软件和数据库，识别业务流程、重复字段、数据断点和权限冲突，进而生成实施路线图。

这套方法帮CMG看清了Agent适合部署的节点，以及上线前必须先清除的障碍。

据Akin透露，甚至在双方正式启动会议前，June就已协助团队安全部署了一部分能力。

**AI先造了一支FDE军团**

CMG的遭遇绝非个案。随着企业纷纷将Agent塞入工作流，一个新岗位正迅速升温：FDE。

该岗位最早由Palantir推广。与传统软件工程师不同，FDE不只负责开发，还需直接进入客户现场，理解业务流程，将AI系统接入真实工作环境，并帮企业拿到实际回报。

但这类人才极难寻觅。根据C&T的研究，美国目前真正具备此能力的工程师仅约2000人——这不是空缺数，而是符合条件的人才总数。

TechCrunch援引该研究指出，这些人需兼具行业知识、企业沟通能力及推动力，并有实际AI部署经验，才能持续帮企业从AI投入中获益。

而企业需求正爆发式增长。

2026年初，仅约5%至10%的企业计划招聘FDE；至第二季度末，这一比例飙升至约70%。大型咨询和服务公司也计划将相关团队扩大10倍。

此事在软件时代亦有先例：无论是ERP还是CRM，企业购软件后均需实施顾问进场适配业务；如今，Agent入场重新催生了类似角色。

但此类模式存在天然限制：高度依赖高成本人力。

一个企业部署Agent，可能需要工程师先搞懂几十套软件、数百个数据字段及数十年业务流程。

若每家企业都需一支FDE团队，AI规模化落地速度仍将受限。

而这正是June试图攻克的难题。

2026年8月3日，TechCrunch报道，企业AI部署创业公司June完成2000万美元Pre-seed融资。

本轮由Marc Benioff旗下Time Ventures领投，Michael Dell、Aaron Levie和George Kurtz等企业软件与云计算领域大佬参投。

创始人之一Rapoport称，这轮融资连商业计划书都没准备。

这并非June创始团队首次创业。Rapoport与Ohad Hen、Barak Goldstein、Idan Tsitiat曾共同创办语音分析公司Bonobo AI。2019年，Bonobo被Salesforce收购，团队随后加入Salesforce，参与其AI业务。

可以说，上一家公司解决的是“让AI理解客户对话”，下一家则是“让AI理解整个企业系统”。

投资人迅速下注，不仅因四人有过一次成功退出，更因他们指向的问题已成为整个企业AI行业的共同焦虑。

Rapoport直言：“AI反而增加了企业对专业服务的需求。”

一家银行的授信流程无法直接复制给航空公司，同一家公司的销售与财务部门也可能使用不同数据标准。模型供应商每进入一个大客户，都要重新理解业务、打通数据、配置权限并设计容错机制。

OpenAI已证明，单纯卖模型不足以拿下企业市场。它正补齐部署能力：通过Frontier Alliance联合BCG、麦肯锡、埃森哲和凯捷等咨询与系统集成伙伴，助推AI改造。2026年5月，OpenAI成立OpenAI Deployment Company，并收购应用AI咨询公司Tomoro，获得约150名FDE和部署专家。该公司启动时获超40亿美元初始投资，进一步押注企业AI落地市场。

亚马逊行动更直接。今年7月底，AWS宣布投入10亿美元组建前线部署工程团队，派工程师进入客户组织，帮其在几天而非几个月内搭建Agent系统。

Anthropic、Google Cloud、Stripe等公司也在扩充类似岗位。部分美国FDE职位基本年薪已达17万至20万美元，OpenAI开出的上限一度达到34.5万美元，尚不含股权。

企业缺乏的显然不再是一套Agent产品，而是一支既懂模型、又懂软件和业务的工程队。

Palantir的成功证明，部署团队不仅是成本中心，更是销售和续约的核心壁垒。工程师留在客户身边，能迅速发现真实需求，帮产品团队纠偏，还能建立普通SaaS难以形成的客户黏性。

问题是，这种模式很难无限复制。

每增加一个客户，可能需增配一批工程师；每家公司都有历史包袱，前一个项目积累的经验未必能完整复用于下一个。只要交付仍高度依赖人力，Agent公司的毛利率和扩张速度就会受制于人。

更棘手的是，客户可能陷入另一种熟悉困境：过去被软件供应商锁定，现在被部署工程师锁定。系统确实跑起来了，却只有少数外部人员知晓其运行逻辑。一旦这些人离开，企业又得到一个黑箱。

Akinmade在试用June前话说得很直白：若该产品仍需FDE，他不要；他不想再得到一套只有少数人能懂的东西。

目前看来，June通过了考验。

**谁能吃掉“擦屁股”这门生意**

过去，企业忍受系统混乱，是因为旧系统虽低效但至少能转。员工靠经验填补数据断点，管理层也不愿为提升一点效率，冒险改造核心业务。

Agent推翻了这套逻辑。它承诺接管一整段工作，而非单纯提效百分之几。

要兑现承诺，企业必须系统清理数据、重划权限，并将那些依赖口耳相传的流程正式写入软件。

这使得“给旧系统擦屁股”从维护费用变成了一门增长生意。

June想吃掉的正是这部分预算——它试图将FDE工作拆解为软件流程：先自动诊断，再出改造路线，最后逐项搭建。

若同类数据冲突、权限结构和工作流能在不同企业间复用，June就能将过去按人天收费的项目，转化为可规模化销售的产品。

这是一笔比再造一个Agent更具吸引力的生意。

模型能力日益趋同，调用价格持续走低。企业可在OpenAI、Anthropic、Google乃至开源模型间切换，却难轻易更换已梳理完成的数据和业务结构。

企业不是一张等待AI书写的白纸。它更像一栋不断加盖、从未彻底维修的老楼：地下埋着废弃管线，墙后藏着临时电路，每一任管理者都留下只有自己懂的改造痕迹。

模型公司送来越来越聪明的机器人，却发现进门后，首要任务不是工作，而是看懂楼的结构，防止哪天牵一发而轰然倒塌。

谁替企业完成这次清理，谁就更可能占据Agent与旧系统之间的控制层。

June并非唯一试图解决此问题的公司。但“擦屁股”这门生意最终花落谁家，尚无定论：

第一种可能，是June这类创业公司将部署工作产品化。

它们不拥有最强模型，也不掌控企业原始系统，却能保持中立：同时接入不同模型和SaaS产品，帮客户选择最优组合。若产品确能减少驻场人员，这类公司将直接冲击传统咨询公司和系统集成商。

第二种可能，是Salesforce、ServiceNow等SaaS巨头自己拿走这笔钱。

它们最懂自家系统数据结构，也控制着企业最重要的业务入口。Agent越需读取客户、员工和订单数据，这些旧SaaS就越难被绕过。

June证明市场成立后，SaaS公司既可复制其功能，也可直接收购。

这将导向与“SaaS末日论”截然不同的结果：Agent非但未摧毁传统软件，反而延长了其寿命。

企业不会用自然语言临时搓出一套世界500强级别的CRM，更不敢让来历不明的Agent直接接管财务和人事系统。Salesforce、Workday和ServiceNow长期积累的客户数据、权限体系和合规记录，恰是Agent进入企业时必须依赖的基础——Agent越强，这些系统作为“事实来源”的价值越大。

第三种可能，也是对AI行业最不性感的一种：企业技术债根本无法被彻底产品化。

修改数据字段看似技术活，实则在重新划分部门权力。取消一道审批程序，意味着有人失去控制权；统一两套客户标准，意味着某部门须承认过去数据不可靠；让Agent接管一段流程，还涉及出错时由业务负责人、软件供应商还是模型公司担责。

这些问题不可能仅靠扫描数据库解决。

若企业改造核心始终是组织协调而非技术诊断，那么最终赚得最多的，仍可能是Palantir、埃森哲、麦肯锡等拥有庞大交付队伍的公司。模型公司卖出更多Agent，咨询公司就获得更多实施项目。AI号称减少白领劳动，率先创造出来的却是一支更昂贵的技术顾问大军。

June能否跳出第三种坏结局，取决于几个尚未回答的问题。

它进入一个客户后，需多少员工参与？不同企业间有多少诊断结果可复用？收费依据是软件订阅、实施项目还是业务效果？若June建议删除某字段导致合规事故，谁来担责？

更关键的是，它能否公开一批非创始团队亲自陪跑、却仍成功上线的客户案例？

一家号称替代FDE的公司，不能依靠更多FDE证明自己。

CMG的案例目前仅证明，June比此前的架构师和顾问更快找到了问题。但它尚未证明，这种能力能脱离几名拥有多年Salesforce经验的创始人，稳定复制给成百上千家企业。

CMG不缺Agent，不缺模型，也不缺采购预算。它缺的是一张能说明旧系统如何运转、何处可拆除、出问题谁负责的地图。

Akinmade不想要只有少数人能懂的黑箱。但在企业AI真正实现标准化之前，能打开这些黑箱的人，可能比黑箱里的Agent更贵。