Ema 于 2026-09-23 宣布完成 7700 万美元 B 轮、累计融资 1.4 亿美元，其智能体按任务与业务结果计价，而非席位或 token。 这条商业动态落在「前置部署」Forward Deployed Engineer（FDE）的收入侧：Ema 卖的是按结果计价 outcome-based 的智能体交付，直接顶掉传统系统集成商与咨询公司按人天与工时报价的集成与实施工作，而「前置部署」Forward Deployed Engineer（FDE）的岗位本身就长在这条交付链上，客户预算此消彼长的正是同一个池子。同一时间，TechCrunch 在报道里写明 OpenAI 已组建 Forward Deployed Engineer 团队进驻客户把 AI 推进生产环境，说明模型厂商与智能体平台正在同一批预算里正面竞争，这是「前置部署」Forward Deployed Engineer（FDE）今年最需要读懂的市场结构变化。 先把事实钉死。Ema 于 2026-09-23 在官网发布 B 轮公告，融资金额 7700 万美元（US$77 million），领投方是总部在班加罗尔的 Creaegis，老股东 Accel、Section 32、Prosus 三方全部加注。累计融资额达到 1.4 亿美元（US$140 million），公司称估值较 2024 年上一轮翻逾四倍，但拒绝披露具体数字。本轮全部是一级股权，不含债务，也不含老股转让。上一轮是 2024 年 3 月的 2500 万美元，由 Accel、S32 与 Prosus Ventures 领投。 公司背景决定这条动态的适用范围。Ema 由前 Google 与 Coinbase 高管 Surojit Chatterjee、前 Okta 高管 Souvik Sen 于 2023 年创立，总部在加州山景城 Mountain View，办公室分布在班加罗尔、伦敦与温哥华，员工接近 200 人。它自称卖的是「AI 员工」，本质是协调多个智能体跨企业既有应用跑完多步业务流程，而不是一次只回答一个问题的聊天机器人 chatbot。客户名单里有 NTT DATA、Hitachi、ADP、PwC、Google、KPMG、Wipro 与 Microsoft。这份买方名单同时也是「前置部署」Forward Deployed Engineer（FDE）最常见的三类雇主：系统集成商、咨询机构与云厂商。 最该被「前置部署」Forward Deployed Engineer（FDE）抄走的是计价口径的改动，这里必须讲清前后差别。 改动前，企业 AI 项目的「报价基准」是软件席位与消耗的 token 数，客户先买许可、再按用量结算，交付方的主要风险落在「客户用不起来」之外；改动后，Ema 明确不按席位、也不按 token 收费，而是按完成的任务与业务结果收费。这个切换直接改变风险分摊：卖席位时用量上不去是客户自己的账，卖任务时用不起来就是交付方自己担。这套「任务计价」口径「前置部署」Forward Deployed Engineer（FDE）可以直接搬进报价模板。Chatterjee 把续约表现归因于此：已有超过 90% 的客户在首个用例之外继续扩容，「净留存」 net dollar retention 约 180%。 第二个改动是交付形态从「订制交付」转向「产品化交付」。改动前的行业默认做法是每个客户一套订制集成，收入随投入人力线性增长；Ema 的路径变成先用平台包住客户既有应用、再让客户自己往外扩，公司自述毛利率因此保持在接近 80%。领投方的公开评价把这一点说得很直白：Creaegis 管理合伙人兼首席投资官 Prakash Parthasarathy 称，Ema 是「可扩展的产品平台加异常经济性，而不是依赖订制实施的服务模式」。公开材料里没有给出与人力外包型交付的毛利率对照，所以这句话只能当作投资方的立场表述，不能当成行业基准。 交付基准是这条动态里最可复用的部分，逐条列清，并标明每条的来源口径。 Wipro 的部署规模最大。公司官网 B 轮页面写明：这套员工助手覆盖 65 个国家，自动化 100 多个工作流，每年处理 2.9 百万次查询（2900000 次），响应时间从 5 天压到秒级，HR 运营成本（HROps）下降 50%，员工满意度提升 20%，60% 的工单在正式开单前就被解决。Wipro 的员工覆盖人数是 240000 名（24 万），这一条来自公司对外新闻稿口径，官网 B 轮页面本身没有重复这个数字。 日立 Hitachi 的部署给的是周期基准：从概念验证到全面投产用了不到 4 周，集成超过 20 个企业系统，支持工单量下降 30%，员工效率提升 70%。另一家前五大全球外包商给的是峰值规模基准：每年处理超过 100 万张 IT 服务工单与超过 100 万通电话，覆盖 15 种以上语言，准确率最高 95%，升级到人工 escalations 的比例低于 10%。公司还提到一个 500 亿美元规模的集团 conglomerate 客户在 4 周内从概念走到生产，连接 20 多个系统、覆盖 40000 多名员工。这四组数字给了「前置部署」Forward Deployed Engineer（FDE）三条可对照的「交付基线」：周期上界是 4 周，系统「集成数」上界是 20 多个，任务「服务水平」上界是准确率 95% 与转人工低于 10%。 增长与留存数字决定这个模式能不能持续，也是客户谈判时的筹码。公司称收入在 24 个月内增长 50 倍，合同预订额超过 1.5 亿美元（US$150 million），毛利率接近 80%，已处理超过 500 万次操作与查询，活跃企业用户超过 100 万，活跃企业项目超过 50 个，可调用的模型超过 150 个，跨越多家前沿模型与开源模型。这里必须同时标明口径：1.5 亿美元是包含 2 年到 3 年合同总额的预订额 bookings，不是年度经常性收入 ARR，公司拒绝披露当前的年化收入运行率。「前置部署」Forward Deployed Engineer（FDE）在与平台方谈判时，应该先要求对方把 bookings 与 ARR 两个口径分开写进材料。 为什么这套东西卖得动，逻辑在预算归属和买方身份。 企业过去把集成、实施与咨询这一整段工作外包给系统集成商与咨询公司；Ema 的定位是把这一段收进平台，按完成任务数结算。对「前置部署」Forward Deployed Engineer（FDE）来说要读出的是：客户并没有新增预算，而是把原来付给人天与工时的钱，转到按任务的计价方式上，所以这是同一笔「采购」 procurement 预算内部的重新分配，不是新增市场。更直接的证据在客户名单结构上：买方里既有 NTT DATA、Wipro 这类本身就是系统集成商的公司，也有 PwC、KPMG 这类咨询机构，也就是卖方服务体系自己在采购这套工具，而这一层正是「前置部署」Forward Deployed Engineer（FDE）所在组织的采购决策层。 另一条商业信号来自第三方评价。Ema 于 2026-09-10 拿到 HFS Research 的 Services-as-Software 转型一等奖，这类奖项的评审口径就是把「服务」重新装成「软件」，与本文讨论的计价切换是同一件事。同期 OpenAI 用 40 亿美元级别的资金搭建部署子公司、Anthropic 与黑石设立合资公司，两家都在把交付能力做成独立业务单元，这条路径的「样板客户」已经从概念验证走到了生产环境。 作者与公司自己承认的局限、以及公开材料留下的空白，必须写全，这几条决定上面数字能用到什么程度。 第一条，全部运营数字都是公司自述口径。240000 名员工、2900000 次查询、工单减半、满意度加 20%、准确率 95% 这些数字，来源是 Ema 官网与公司对外新闻稿，两者同源，没有第三方审计，也没有披露任何改动前的对照基线。TechCrunch 的报道同样只转述公司口径，没有独立核验。 第二条，预订额不能当收入用。1.5 亿美元含 2 年到 3 年合同总额，公司拒绝披露 ARR，所以无法据此换算真实增速，「收入增长 50 倍」也没有给出起点基数，绝对规模依然不明。 第三条，估值口径无法验证。公司只说翻逾四倍，前后两轮的具体估值都没有披露，既算不出收入倍数，也无法与其他智能体公司横向比较。 第四条，存在选择性披露。50 多个活跃项目里只有 Wipro、Hitachi、一家外包商与一个未具名集团给出了量化结果，其余客户没有数字；同时 240000 这个人数是「可覆盖人数」还是「实际使用者」，公开材料没有区分。 第五条，「一个任务」的边界没有公开规则。按任务与结果计价的合同风险恰恰在定义里：什么算完成、失败重跑算不算、跨系统的半成品怎么计费，公开材料一律没有回答。对「前置部署」Forward Deployed Engineer（FDE）来说这是最大的合同风险点，本条只能给出提问清单，给不出答案。 第六条，未覆盖的场景要主动点名。受监管行业常见的物理隔离 air-gapped 私有化部署、数据不出境要求，公开材料没有说明是否支持；虽然公司称集成 250 个以上业务应用，但这些都是主流商业软件，遗留系统与客户自研系统不在其中。公司称随部署积累会逐步减少人力投入从而改善毛利，但没有披露单客户的人力投入曲线，这条推论无法验证。 该行动的是两类人，动作可以立刻做，不必等这类平台进自己的客户现场。 第一类是在给企业 AI 项目做报价的「前置部署」Forward Deployed Engineer（FDE）与配合作战的商务同事；第二类是所在组织本身就是系统集成商、正在评估要不要引入同类平台替换部分人天交付的交付负责人。两类人面对的是同一个问题：同样的交付量，按席位、按 token、按人天、按任务，四种口径的毛利与风险完全不同。 具体做法五步。第一步，把报价模板里的席位计价栏目删掉，改成按完成的任务数计价，并在合同附件里写死「什么算完成一个任务」。第二步，用本文的基准做量级校验：240000 名员工、65 个国家、100 多个工作流、年查询 2900000 次这个量级，对应的交付周期上限参考是 4 周，系统「集成数」上限参考是 20 多个，这两条只能当上界用，不能当中位数承诺。第三步，把验收条款写全三件事：任务完成的判定规则、失败重跑的计费规则、扩容时新旧任务的计价是否一致。第四步，把退出机制写进合同：要求平台方提供数据与集成配置的导出能力，明确终止后多少天内完成迁移，避免业务流程被锁在单一平台里。第五步，如果客户明确要求数据不出境或私有化部署，先要求平台方书面确认支持范围——公开材料里没有这一项，不要默认可用。 适用条件是：本文的基准只适用于 HR、IT 服务台、财务流程这类高频、跨系统、任务可枚举的场景；创意产出、法务判断、需要跨部门重新定义流程的项目，以及客户坚持自建「订制模型」而不接平台的路线，都不在这些基准的射程内。单客户员工规模低于 5000 人时，240000 名员工那条基准不具参考价值，这时应该改用同一批公开材料里的外包商基准（年 100 万张工单、准确率 95%、转人工低于 10%）来判断自动化率是否合理。 回滚与退出方式是两层。计价口径这一层可以在下一份合同生效日退回席位或人天口径，不涉及技术改造，前提是第四步的导出条款已经落地；平台这一层的退出完全依赖导出条款，所以在签署前把导出格式与时限写死，是唯一真正可控的退路。对「前置部署」Forward Deployed Engineer（FDE）来说，把「回滚只换计价口径、不动数据与集成配置」写成验收条款，是这场谈判里最容易拿到、也最容易被忽略的一条安全边界。 原始来源： - https://ema.ai/series-b - https://www.ema.ai/news - https://techcrunch.com/2026/09/23/ema-raises-77m-as-ai-starts-eating-into-enterprise-software-and-services/