文 | 字母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 只需在这条平整的跑道上证明自己速度够快即可。
但在现实的企业系统中，整洁是种奢望。
一家运营十余年的公司，通常并行使用 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 人——这并非空缺岗位数，而是符合要求的人才总数。
TechCrunch 引用该研究指出，这些人需兼具行业知识、企业沟通能力及推动力，辅以实际 AI 部署经验，才能持续助力企业从 AI 投入中获益。
而企业需求正呈爆发式增长。
2026 年初，仅约 5% 至 10% 的企业计划招聘 FDE；至第二季度末，这一比例飙升至约 70%。大型咨询和服务公司也计划将相关团队扩大十倍。
此事在软件时代亦有先例——无论是 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 更贵。
