文 | 字母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毫无准备。作为美国抵押贷款公司，CMG近年一直在探索AI引入业务流程。公司已开始使用Claude Code辅助软件开发，证明了工程团队快速采用新工具的能力。
在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更贵。
