企业采购 Agent，正在变得越来越容易。

OpenAI、Anthropic、Google 和微软都在争夺企业客户，Salesforce、ServiceNow、Workday 等 SaaS 公司则忙着把 Agent 塞进每个产品页面。

可以说，购买 Agent 本身已经不是难题。但当企业真正尝试部署这些 Agent 时，新的问题出现了：

买 Agent，并不等于让 Agent 进入工作。

美国抵押贷款公司 CMG Financial 就遇到了这样的困境：其首席战略官 Paul Akinmade 此前曾在 Salesforce 年度大会上承诺，公司下一阶段将推动 100 个 Agent 投入运行，但事情并没有他想象中那么容易。

此前，CMG 已经将部分软件开发工作迁移到 Claude Code，证明团队能够快速采用最新 AI 工具，可当团队试图让 Agent 进入 Salesforce、参与真实业务流程时，项目突然慢了下来。

他们很快发现，Agent 可以写代码、调用 API，却无法理解一家企业多年积累的数据、权限和业务流程。

类似的问题正在整个行业出现。根据猎头公司 Christian & Timbers（C&T）的一项行业研究，美国目前真正具备将 AI 系统部署进企业、并帮助客户获得可量化回报能力的前线部署工程师（Forward Deployed Engineer，FDE）仅约 2000 人。

随着企业从 " 尝试 AI" 进入 " 规模化部署 AI"，大型咨询和服务公司正在快速扩充这类团队。

AI 产业由此出现了一个略显讽刺的转折：企业已经不太缺 Agent，真正稀缺的是能替它收拾旧系统的人。

最后帮 CMG 找到路的，是一家名为 June 的创业公司。

100 个 Agent，卡在 Salesforce 里

大模型公司演示 Agent 时，通常会给它一个干净的环境。

数据已经整理好，接口已经打通，任务边界清晰，调用权限也经过预设。Agent 需要完成的，是在一条平整的跑道上证明自己跑得足够快。

然而，现实中的企业系统很少如此整洁。

一家经营了十几年的公司，通常同时使用 Salesforce、ServiceNow、Workday、Databricks 以及一批自建系统。一名客户可能出现在四个数据库中，拥有四个编号、三个状态和两个负责人。系统之间还可能保留着历次组织调整、产品改版和管理层更替留下的痕迹。

这些痕迹并不都是技术错误，只是不同部门之间的判断标准不同：销售部门可能按照是否产生商机判断 " 活跃客户 "，财务部门则按照是否发生回款判断；客服认为客户关系已经终止，合规系统却要求继续保留其档案。

每个字段背后都有一套部门利益、责任边界和历史原因。

在传统软件中，出于员工经验，这些矛盾的数据可以被人暂时消化。老员工知道某个字段虽然名为 " 客户状态 "，实际上已经两年没人更新；财务人员知道导出报表后还要手动修改三列；销售经理也清楚，系统里显示已经关闭的项目仍有挽回机会。

但 Agent 没有这些经验，更不会产生这种默契——它只能认真地读取每个字段，按照被授予的权限执行指令。

很多过去靠人类经验勉强维持的系统漏洞，在 Agent 面前，就变成了必须解决的大问题。错误的客户状态可能导致一封不合时宜的营销邮件，错误的贷款状态却可能触发风控、合规乃至法律责任。对 Agent 而言，这就是一座庞大无边的 " 屎山代码 "。

这正是 CMG 遇到的障碍。

CMG Financial 并非对 AI 毫无准备，事实上，作为美国一家抵押贷款公司，CMG 近年来一直在探索如何将 AI 引入业务流程。公司已经开始使用 Claude Code 辅助部分软件开发工作，也证明了其工程团队能够快速采用最新 AI 工具。

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

此前，CMG 首席战略官 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 适合部署在哪里，以及上线前必须先解决什么问题。

据 Akinmade 称，June 甚至在双方正式启动会议之前，就已经帮助团队安全地部署了一部分能力。

AI 先制造了一支 FDE 军团

CMG 遇到的问题并不是个例。随着企业纷纷把 Agent 塞入工作流，一个新的岗位正在快速升温：FDE。

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

但这类人才并不容易找到：根据猎头公司 Christian & Timbers（C&T）的一项研究，美国目前真正具备这种能力的工程师大约只有 2000 人——这个数字指的不是空缺岗位数量，是符合要求的人才，一共只有 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 更贵。