昂贵的 Token 救不了企业 AI

Anthropic、OpenAI、AWS、Microsoft 正在为同一个缺口投入数十亿美元：需要工程师把模型能力变成企业真正拥有、能够持续改进的工作流。

Forward Deployed Engineering（FDE）已经成为企业 AI 最清晰的信号之一。把 Anthropic、OpenAI、AWS、Microsoft 最近的公告放在一起看，四家公司都在把工程师推到更靠近客户的位置。OpenAI 和 AWS 直接使用 FDE 这个名称；Anthropic 和 Microsoft 的叫法不同，押注的却是同一件事。

模型已经会写代码、读文档、调用工具。企业真正缺的，是把数据、权限、审批、恢复和责任组织成一套能在生产环境稳定运行的工作系统。FDE 就站在这个缺口里：工程师把模型接进真实工作，再把现场暴露的问题变成更好的部署，并尽可能送回产品。

75 亿美元说明，AI 的瓶颈在落地

59 天内，四家 AI 平台先后宣布成立大型部署组织。Anthropic 成立了一家面向中型企业的 AI 服务公司。OpenAI 推出由自己控股的部署公司，初始投资超过 40 亿美元，并同意收购 Tomoro，带入大约 150 名 FDE 与部署专家。

AWS 投入 10 亿美元，计划把数千名专家嵌入客户团队。Microsoft 则为 Frontier Company 投入 25 亿美元，配置 6000 名行业和工程专家。

这些投入的口径并不完全一致，但共同说明：当前 AI 真正稀缺的，不是更多模型能力，而是把数据、权限、系统集成和业务责任组织成真实结果的部署能力。

软件公司为什么要花数十亿美元养一支庞大的工程队伍？因为这些工程师同时承担两个任务：帮助客户把系统做成，也告诉模型公司哪些现场问题值得变成产品。如果每支团队都在手工解决同一种连接器、权限、评估或工作流故障，FDE 只是昂贵的定制服务。只有当重复问题被沉淀进产品，这个模式才可能规模化。

FDE 到底在现场做什么

Palantir 把 FDE 定义成一种产品开发方式，而不只是实施岗位。工程师进入工厂、运营中心等真实现场，和用户一起工作，再与核心工程团队协作，把现场反馈变成产品改进。Palantir 把这个过程称为由人完成的反向传播。这个说法听起来有些学术，实际工作却很具体。

假设一家制造商遇到供应中断。供应商信息在一个系统里，生产能力在另一个系统里，客户订单又在第三个系统里，审批规则可能只存在于员工经验中。真正有价值的问题不是“这里能不能加一个聊天机器人”，而是“这个供应商出问题以后，哪些订单会受影响，计划人员有哪些选择，谁有权批准调整”。

FDE 会和一线人员一起拆解这个问题。团队连接相关数据，定义工厂、生产线、供应商、订单等关键业务对象，再把真正需要采取的动作接进去：更新采购单、调整配送策略、模拟供应中断。权限、审批和失败后的处理方式，从一开始就是系统的一部分，而不是上线前补的一叠文档。

接着，系统必须接受现场检验。计划人员发现了一个例外，某个数据源来晚了，审批规则挡错了人。FDE 可以修复当前部署，更有价值的是判断这个问题会不会在其他客户身上重复，再把经验送回核心产品。

这就是由人完成的反向传播：发现问题，做出可运行的系统，观察真实失败，改进产品，再让下一次部署从更高的起点开始。对技术人员来说，真正有价值的信号不是“离客户近”本身，而是把混乱的业务现场翻译成软件，在真实约束下保持工程严谨，并判断哪些局部经验值得成为可复用的产品能力。

不要被“五分钟 AI”神话欺骗

如果有人告诉你，只用几句 prompt、五分钟就让 AI 写出了一篇真正优秀的文章，他隐去的是支撑结果的整套生产系统。Prompt 可以启动一次生成，却维护不了一套高质量工作流。

我的第一版博客流程连通了调研、大纲、写作、翻译、配图、音频、视频和发布，产出速度明显提高，质量却没有自动提高。证据薄弱、生硬翻译、重复配图、失效链接和过期音视频，仍然可能顺着流程一路通过。

第二版需要我更深地参与：重读、拒绝、质疑证据、比较视觉方向、测试链接，再决定哪些修正应该成为长期规则。工作流之所以提高，是因为判断被写回了系统，变成证据门、编辑检查和验证工具。

这其实就是一个缩小版的 FDE 过程：贴近真实工作，发现通用能力遗漏的问题，再把局部修正写回系统。企业部署的规模和风险当然高得多，但工作方式相同。至少在现阶段，AI 能执行的环节远多于它能负责的环节；没有人持续设定质量标准并维护系统，Recursive 很容易变成重复生成，而不是自我提升。

目标不是永远手工操作，而是让每次参与都能沉淀，让下一次运行从更高的基线开始。不要把自动生成误认为自动生产，更不要把自动生产误认为自我提升。

不要简单地把 FDE 和咨询画等号

把 FDE 理解成咨询顾问的重新包装，是一种很片面的看法。优秀的咨询顾问和系统集成商，本来就在分析工作流、建设技术、推动组织变革、处理监管问题和协调大型转型，FDE 并不独占这些能力。

更值得关注的区别，是现场工作与产品之间的连接。在理想的 FDE 模式中，团队既靠近生产环境，也靠近核心工程。一次部署中学到的东西，可以改变平台，并缩短下一次部署。

职位名称本身什么也证明不了。如果项目结束后只留下定制代码、一次交接，以及对厂商更深的依赖，它仍然是定制服务；如果客户能够运行建成的系统，现场经验也能改进产品，FDE 才真正形成了不同的工作方式。

FDE 不会替代咨询，企业 AI 落地仍然需要工程、产品判断、安全、治理和变革管理。它的价值，是缩短这些专业与真实软件之间的距离。

企业必须把工作流沉淀在自己手里

厂商越接近核心工作流，越可能创造价值，也越可能把依赖藏得更深。一个关键流程可能逐渐绑定在某家厂商的连接器、评估体系、权限模型、智能体运行环境和默认假设上。系统看起来很成功，企业理解和改变它的能力却可能越来越弱。

因此，企业必须掌握工作流中真正耐用的部分：数据契约、评估集、权限规则、审计记录、运行手册、失败模式，以及工作流与模型之间的接口。内部人员应该知道系统为什么有效、可能在哪里失败，也应该能够在更换模型或合作伙伴时，不必把业务流程推倒重来。

一次好的 FDE 合作，应该让客户自身变得更有能力，而不是更依赖一家有能力的厂商。企业付费建设的应该是运营能力，而不是租用一个结果。

ACTOR：我的 AI 落地执行框架

ACTOR 是我在实际工作中用来推动 AI 落地的执行框架。它不是一套普遍真理，而是为了避免一个项目仅仅因为“模型生成了东西”，就被宣布成功。

这篇文章本身就是一个现实例子。Action 不是“生成文字”，而是发布一篇来源可靠、双语一致、图片和链接都能正常工作的文章。Context 包括一手资料、过去的文章、语言规则和目标读者。Trust 允许 AI 调研、起草、翻译和提出配图，但事实判断、文章结构、视觉选择和最终发布仍由我负责。Outcome 也不是字数或 Token 使用量，而是论证是否成立、成品是否通过验证、读者反馈是否真的有用。

Recursive 就发生在这次修改里。读者指出“四项产出”与 ACTOR 形成了两套竞争框架。我删掉了前者，并把“一篇严肃文章只保留一个主要执行框架”写进工作流。当前文章因此更清楚，下一篇文章也会从更好的约束开始。

这就是我实际使用 ACTOR 的方式。企业场景的数据更多、风险更高、责任人更多，但在宣布部署完成之前，仍然必须说清楚行动、背景、信任、结果和学习。

Token 是投入，不是结果

Token 使用量只能衡量模型消耗，不能说明决策有没有改善、流程有没有变快、组织有没有学到东西。真正重要的产出，是一项被可靠改变的工作：它能够稳定运行，仍在企业控制之下，并且会在使用中继续提高。

Anthropic、OpenAI、AWS、Microsoft 建设部署组织，是因为模型能力本身无法完成工作。它们押注的是：现场工程师能够缩短智能与运营之间的距离。AI 很快还会产生新的职位名称，但第一性原理不会变：能力只有在改变真实工作、经得住生产环境，并让组织更有能力运行下一条工作流时，才会产生价值。

我最终会保留一条执行规则：判断 AI，要看它改变了什么工作流、客户留下了什么能力，而不是消耗了多少 Token，或者团队挂着什么职位名称。真正的问题不是 FDE 这个名称会不会流行，而是企业能不能把昂贵的 Token，变成自己真正拥有的运营系统。