文 | 字母AI
企业采购Agent这件事，门槛正在肉眼可见地降低。
OpenAI、Anthropic、Google和微软这几家大模型巨头正虎视眈眈地盯着企业客户；另一边，Salesforce、ServiceNow、Workday等SaaS厂商也没闲着，恨不得把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产业由此出现了一个充满讽刺意味的转折：企业现在不缺Agent了，真正稀缺的是那些愿意替它收拾旧系统烂摊子的人。
最终帮CMG理清头绪的，是一家名叫June的初创公司。
**100个Agent，为何卡在Salesforce里？**
大模型公司在演示Agent时，通常会给它准备一个无菌环境。
数据已经清洗完毕，接口早已打通，任务边界清晰明确，调用权限也经过精心预设。Agent只需要在这条平整的跑道上，证明自己的速度够快就行。
但现实中的企业IT架构，很少有这么干净利落的时候。
一家经营十几年的公司，往往同时并行着Salesforce、ServiceNow、Workday、Databricks以及一堆自建系统。同一个客户可能在四个数据库里留下痕迹，拥有四个不同的编号、三种状态和两个不同的负责人。系统之间还夹杂着历次组织架构调整、产品改版和管理层更替留下的历史尘埃。
这些遗留痕迹未必全是技术bug，更多是不同部门立场差异的结果：销售部可能根据是否产生商机来定义“活跃客户”，财务部则看是否有回款才算数；客服觉得客户关系已终止，合规系统却要求继续保留档案。
每个字段背后，都牵涉到部门利益、责任划分和历史包袱。
在传统软件时代，靠老员工的经验，这些矛盾的数据尚能被勉强消化。资深员工清楚，某个名为“客户状态”的字段其实两年没人更新过；财务人员知道导出报表后还得手动修正三列数据；销售经理也明白，系统里显示关闭的项目仍有挽回余地。
但Agent没有这种职场默契，也不具备人类经验——它只会机械地读取每个字段，严格按授予的权限执行指令。
过去靠人力经验勉强维持的系统漏洞，在Agent面前瞬间变成了必须解决的重大障碍。错误的客户状态可能导致发出不合时宜的营销邮件，错误的贷款状态甚至可能触发风控、合规乃至法律责任。对Agent而言，这就是一座庞大且混乱的“屎山代码”。
这正是CMG面临的真实障碍。
CMG Financial并非对AI毫无准备。作为美国一家抵押贷款公司，近年来一直在探索AI在业务流程中的应用。公司已开始使用Claude Code辅助软件开发，并证明了工程团队快速接纳新工具的能力。
在Salesforce生态中，CMG希望进一步扩大AI的应用边界。
此前，CMG首席战略官Paul Akinmade在Salesforce年度大会上立下Flag：下次回到大会时，公司希望能看到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系统接入实际工作环境，并确保客户能获得切实回报。
但这类人才极难寻觅。根据猎头公司Christian & Timbers（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更贵。