OpenAI的FDE将破损的智能体转化为可交付的系统

OpenAI的FDE（前沿部署工程师）模式将半成品的智能体转化为人们实际可交付的系统。

我构建智能体工作流已经很久了，深知它们通常在哪里失败：不是在演示中，不是在提示词里，而是在有人说“看起来不错，我们上线吧”之后的一周。那时问题就开始显现。模型在沙盒中回答得很好，工具已连接，笔记本看起来很整洁，然后真实用户带着杂乱的Data、奇怪的权限、文档不全的API，以及企业在你已经编码完流程后改变过程的经典习惯找上门来。我见过团队花数月时间打磨智能体行为，然后因为没有人负责部署、监控、备用路径或采用过程中无聊的人力部分而输掉整个项目。这真是令人恼火，因为失败模式是完全可以预见的。智能体不够“聪明”。团队尚未“准备好”。工作流没有被“产品化”。所有这些通常不过是在礼貌地说，没有人足够贴近客户来完成工作。

这就是为什么当我看到知乎专栏文章阐述OpenAI的FDE战略，以及该公司建立一个专注于部署的部门并派人进入客户账户让事情在实践中运转起来时，我格外关注。这篇文章通过“前沿部署工程师”这一概念来阐述，并将其与OpenAI收购Tomoro以及更广泛地与Anthropic竞争联系起来。我不把这篇文章当作绝对真理，因为它是一篇评论，而非官方公告。但其中的核心模式不容忽视：销售模型的公司正在更贴近实施环节，而这改变了我对智能体项目的思考方式。

每个人都在忽略的部分：部署即是产品

OpenAI成立Deployment Company，融资40亿美元，收购咨询公司Tomoro，派出“前沿部署工程师”（FDE）进驻企业，手把手帮客户调系统。

这实际意味着很简单：模型不再是全部。部署动作、集成工作、在客户环境中调试以及围绕采用进行的手把手指导，现在都是产品的一部分。如果你一直把智能体工作视为“构建提示词、连接工具、交付”，那你一直漏掉了最昂贵的部分。

我在内部copilot项目中反复遇到这个问题。原型在受控审查中给所有人留下深刻印象，然后IT部门问起日志记录，法务问起数据保留，实际用户会说答案质量很好，但输出不符合他们的工作流程。这不是模型问题，这是部署债务（Deployment Debt）。

OpenAI的FDE想法基本上是在承认，通用支持是不够的。必须有人坐在客户身边，理解系统，并不断调整，直到系统在与现实接触后存活下来。如果你见过顾问花三天时间仅学习客户的命名约定和审批链，你就已经理解了这一点。

如何应用：停止将智能体的成功定义为“它在评估中回答正确”。将其定义为“一个已命名的客户可以在其实际流程中使用它，无需额外努力”。这意味着你需要负责人来推进发布、集成、变更管理和后续跟进。如果你没有这个人，你就没有生产计划。

FDE为什么存在：演示与厌恶之间的鸿沟

丑陋的真相是，大多数智能体失败本质上穿着技术外衣的社会失败。演示获得掌声，因为它压缩了复杂性。生产环境则暴露了缝隙。人们需要他们没提到的权限、他们忘记的边界情况，以及与现有工作形式相匹配的输出。如果智能体比旧流程多要求一个字段，即使模型“更好”，用户也会讨厌它。

这就是FDE旨在填补的利基市场。我认为他们是在模型行为与业务现实之间进行翻译的人。他们不仅仅是抽象意义上的工程师。他们是能够与客户坐在一起，找出工作流为何中断，然后修改系统而不将其变成科学项目的人。

咨询公司在企业软件中赚这么多钱是有原因的。软件从来不是唯一的交付物。真正的交付物是“让这个适应我们组织”。正如源文章所述，OpenAI此举的赌注是，模型供应商可以捕获部分服务层，而不是将其全部拱手让给外部集成商。

• 演示成功意味着模型能够回答。
• 部署成功意味着客户能够采用。
• 运营成功意味着客户在第一个月后继续使用。

如何应用：当你规划一个智能体项目时，显式地列出非模型工作。包括数据映射、权限、备用行为、审查循环和用户培训。如果这个列表因为比提示词还长而让你感到尴尬，那很好。这就是现实。

Tomoro是线索：系统胜于聪明

文章提到OpenAI收购了咨询公司Tomoro。如果你想理解其策略，这个细节比标题更重要。收购一家咨询公司不是为了虚荣。而是为了引进部署的肌肉记忆：范围界定、利益相关者管理、实施，以及使企业工作成为可能的成千上万个小调整。

这实际意味着，OpenAI不仅仅试图销售模型访问权。它试图拥有从兴趣到采用的路径。那条路径是混乱的，而混乱的路径要么让软件公司成长，要么让它们陷在无尽的试点炼狱里。

我见过团队构建了漂亮的智能体框架，然后当客户要求自定义路由、审计日志或一种在输出进入下游系统之前冻结输出的方法时，他们感到震惊。模型团队称这为“超出范围”。客户称之为“基本功能”。像Tomoro这样的咨询之所以存在，就是因为有人必须弥合这个鸿沟，而不是假装它不存在。

如何应用：如果你在构建智能体基础设施，有目的地添加一个部署层。不是“锦上添花”的层，而是真正的层。它应该包括入门文档、环境检查、权限验证、回滚步骤，以及每个发布的联系人。如果你无法解释客户如何在一周内从零到获得第一个价值，你的系统还没有准备好。

Anthropic从另一面证明了同样的观点

消息源还提到Anthropic与Blackstone合作。不同的公司，相同的信息：模型供应商正在走向直接的企业参与，因为那里才是真正的工作所在。你可以整天销售API，但如果客户无法将输出可操作化，你销售的是一个非常昂贵的实验。

我不认为这是公司之间某种肤浅的模仿。更像是市场最终承认，企业AI是一个带着软件的服务业务。这会让那些希望模型成为全部故事的人感到不适，但钱和痛点都在那里。

当我听到“合作”时，我通常会问：“谁在做集成？”这个答案告诉了我一切。如果答案是“客户会自己搞定”，那么这个合作就是营销。如果答案是“我们有现场人员，我们正在映射工作流，我们负责发布”，那么我们现在谈论的是一个真正的运营模式。

• 模型访问权获得关注。
• 实施获得预算。
• 采用让合同持续有效。

如何应用：如果你是一个较小的团队，不要复制规模，复制姿态。将部署视为产品的一部分。构建你自己版本的FDE行为，包括一个指定的负责人、客户回访，以及一个直接反馈到智能体设计的循环。

FDE的真正工作是扼杀虚假的信心

这是我最尊重的一点。一个好的部署工程师不会保护团队的自我。他们摧毁那种打磨过的演示等同于准备就绪的错觉。这听起来很苛刻，但它为每个人节省了时间。如果智能体是脆弱的，就说出来。如果客户的流程每周都在变化，就说出来。如果输出需要人工审查，就在有人在幻灯片中承诺完全自动化之前说出来。

我在这段对话的两边都待过。最糟糕的版本是，一个团队不停地说“我们大概能让它工作”，同时暗暗希望客户不会注意到那些缺口。更好的版本是一个直白的清单：什么能工作，什么会失败，什么需要人工，什么需要更多数据。这种诚实体现在能让项目存活。

至少在源材料中描述的FDE模式，本质上是一种制度化的诚实。它表明供应商应该足够贴近现实，以便及早发现裂缝。这比交付一个光鲜的API并祈祷客户有足够强大的工程组织来吸收痛苦要有用得多。

如何应用：在每次发布前创建一个就绪评估。问四个问题：缺少什么数据？哪些权限不明确？哪些输出需要人工批准？模型出错时会发生什么？如果你不能干净利落地回答这些问题，你仍然处于试点阶段。

如果今天我构建智能体，我会从中学到什么

如果我剥去炒作，教训不是“OpenAI在招聘顾问”。教训是，智能体系统需要一种部署纪律，而大多数团队都没有。他们有提示词、评估、也许一个仪表盘，以及一个祈祷。一旦真实用户出现，这些就不够了。

我会从FDE模式中借鉴三件事。首先，让实施与产品团队保持紧密联系，以便客户的痛点能快速反馈回来。其次，让某人对采用负责，而不仅仅是代码。第三，将每次发布都当作一个活的系统来对待，因为它就是。客户环境会变化，工作流会偏移，智能体将需要维护，无论你的路线图是否承认这一点。

如果你是一家初创公司，这一点尤其重要。你负担不起一个庞大的服务组织，但你也负担不起虚假的产品市场契合。因此，构建一个精简的部署职能：一个人负责客户从试用走向生产的路径，一个发布清单，以及一个发布后修复的循环。这能让你获得大部分价值，而无需假装你是一家咨询公司。

如何应用：将部署工件（Artifacts）作为仓库的一部分。不要作为单独的零散知识。将发布清单、升级路径和客户特定备注放在工程师能看到的地方。如果这些知识仅存在Slack中，一旦有人忙碌，你很快就会失去它。

你可以复制的模板

#  智能体部署手册

## 1. 目标
交付一个能在真实客户工作流中运行（而不仅仅在演示中）的智能体。

## 2. 负责人
- 产品负责人：
- 工程负责人：
- 部署负责人：
- 客户联系人：

## 3. 客户工作流
- 当前流程：
- 智能体的切入点：
- 需要的输入：
- 产生的输出：
- 人工审批点：

## 4. 就绪清单
- 所需数据可用
- 权限已确认
- 日志记录已启用
- 备用行为已定义
- 人工审核路径已记录
- 回滚计划存在
- 客户培训已排定

## 5. 失败模式
- 缺少数据：
- 不良工具调用：
- 错误输出格式：
- 权限被拒绝：
- 模型不确定性：
- 客户流程变更：

## 6. 部署步骤
1. 验证环境
2. 连接工具
3. 运行测试用例
4. 与客户一起审查输出
5. 修复工作流缺口
6. 向小用户组发布
7. 第一周每日监控
8. 仅在稳定使用后扩展

## 7. 发布后循环
- 每日问题：
- 每周审查：
- 跟踪的指标：
- 客户反馈来源：
- 下一步修复：

## 8. 成功标准
- 用户无需额外帮助即可完成任务
- 输出适配现有工作流
- 错误可见且可恢复
- 客户在发布后继续使用

## 9. 备注
- 与原始流程相比的变化：
- 模型仍然无法做到的：
- 每次都需要人工处理的事务：

这个模板的目的不是让你的项目看起来有条理。而是迫使那些混乱的部分在它们变成支持工单之前暴露出来。用真实的名字、真实的工作流和真实的失败案例来填充它。如果你无法写下这些，那么智能体还没有准备好。

这就是我希望更多团队理解的一点。智能体工作的未来不仅仅是更好的模型，还是更好的部署习惯。老实说，这是一种解脱，因为习惯是我们实际上可以改进的东西。

来源说明：我正在拆解知乎原始文章中的想法，原文链接为 https://zhuanlan.zhihu.com/p/2054104152914105203。这里的模板和部署框架是我基于该来源的综合分析，而非直接摘录。