AI Agent在Demo时表现优异，上线后却频频失效？问题可能不在技术层面。本文深入剖析隐性知识与情境知识在AI落地中的关键作用，揭示FDE（前沿部署工程师）如何成为破解这一难题的核心角色，并探讨为什么OpenAI、Anthropic等巨头正在大规模布局这一人力密集型岗位。

我最近聊了不少在做 AI 落地的朋友，有一个问题被反复提到：

「为什么我们的 Agent 在 Demo 的时候还挺好用的，真正上线之后就废了？」

我一开始也以为这是个技术问题。模型选型不对？RAG 文档没备好？Prompt 写得不够细？

后来慢慢想明白了——这些解释背后，藏着一个更根本的错误预设。

一、那个错误的预设是什么

大家默认：业务知识是存在于文档里、数据库里、流程图里的东西。所以只要我们把这些材料整理好、喂给 AI，它就能理解业务，就能正常工作。

这个假设在简单场景里没什么问题。问”这款产品有几个 SKU”，AI 查数据库就行。但一旦业务稍微复杂一点，这个假设就开始出问题。

举个例子。一个做了八年医疗理赔的审核专员，她判断一个案子有没有问题，靠的不是那本 SOP 手册。她靠的是某种很难言说的直觉——在处理了几千个”手册里找不到对应条款”的特殊案例之后，慢慢积累下来的东西。

你让她把这套判断逻辑写出来，她写不出来。不是不愿意分享，而是这套东西本来就不是通过文字学会的，自然也没办法通过文字传授。

这就是隐性知识。

为什么这个预设错了，我们却一直没发现？

因为它曾经是对的。过去三十年，绝大多数软件项目做的都是”显性知识的数字化”——把审批规则录进系统，把业务流程变成表单，把客户数据搬进数据库。这类工作里，知识确实等于文档，文档确实等于数据，整个逻辑链条是通的。

问题是，AI 落地的场景和这完全不同。AI 被要求处理的是理解、判断、推断——而这些，恰好依赖的是那些从未被写下来过的东西。我们把一个曾经有效的假设，用到了一个本质不同的场景里。

二、知识有三种，AI 能处理的只有一种

我一直觉得，AI 落地领域有一个被严重低估的认知盲区：我们把”知识”这个词想得太简单了。

绝大多数 AI 项目对付显性知识得心应手，但真正让业务跑起来的，往往是后两种知识——而这两种，你用再多的文档也喂不进去。

再举一个情境知识的例子。

一个有经验的销售在客户拜访快结束时，会感知到”这次不该继续推进”——对方语气里有一点防御，眼神飘了，话头开始绕弯子。这种”读空气”的能力，是长期磨出来的直觉判断，是情境知识最典型的形态。

这次拜访结束之后，那个关键判断节点永远不会出现在 CRM 日志里，也不会成为任何 AI 模型可以学习的训练数据。它就这样消失了。

三、FDE 在解决的，其实是一个认识论问题

这里想介绍一个概念：FDE，Forward Deployed Engineer，前沿部署工程师。

最早由 Palantir 提出并跑通，后来 OpenAI、Anthropic、Cursor 都在大量招这个岗位。

很多人第一反应是：哦，就是售前 + 实施 + 客户成功的三合一呗，全能型乙方。

不是的，差很远。

FDE 的核心动作，是把工程师直接派驻到客户的业务现场。不是去做培训，不是去验收交付，而是和业务专家同桌坐着，当场调 API、写 Prompt、接 Agent，下午就能跑出 Demo。

为什么要这样做？

回到那个做了八年理赔的审核专员。你没办法靠一份访谈提纲把她的知识提取出来。但如果你坐在她旁边，看她实际怎么处理每一个案子，听她说”这个有点问题”的时候顺口追一句”为什么”——你慢慢能拼出那套直觉的大概轮廓。

FDE 的本质，是把”不可言说的业务知识”翻译成”可以运行的代码”。这是一个必须”在场”才能完成的工作。

什么样的人适合做 FDE？

不是随便一个工程师都能做到。FDE 需要一种稀有的”双语能力“——能用技术语言和机器对话，也能用业务语言和领域专家沟通；在两种语境之间实时切换，充当活的翻译层。

大多数工程师在业务现场听到”我们这里有很多例外”，第一反应是”能不能标准化”；好的 FDE 会追问：”哪种例外最常见？背后的逻辑是什么？”前者在化简问题，后者在理解问题——这是两种完全不同的思维方式。

还有一种角度：FDE 比起工程师，更像人类学家。他们在现场的核心工作不是”写代码”，而是”观察”——观察真实的工作流程（通常和文档写的不一样），观察边缘案例如何被实际处理，观察哪些规则在什么情况下会被默默绕过。代码，只是这个观察过程的最终输出物。

四、把四段式研发链路，折叠进一个人、一个现场、一个短周期

传统软件公司的研发节奏大家都熟悉：

PM 收集需求 → 工程师写代码 → 销售拿去卖 → 客户用得别扭 → 反馈回来再改

一个闭环走完，三个月没了。

这条链路慢，不是最大的问题。更严重的是：每一次交接都会丢失一些东西。

• PM 和客户聊了一个小时，整理成需求文档，已经过滤掉了大量”感觉说不清楚的细节”；
• 工程师按文档开发，再次简化了很多模糊的边界；
• 销售按 PPT 介绍，又一次抹平了场景里的微妙差异。

等用户真正拿到这个东西，原始需求里那些隐性的、只能在语境里感知的部分，早已荡然无存。

这不是协作效率的问题，是信息传递的物理限制——隐性知识，在每一次”翻译”里都会进一步流失。

FDE 把这条链路”折叠”了。工程师直接住进客户现场，身兼需求发现者、代码编写者、现场调试者三重角色，把原本切成四段、由四拨人干的事情，压缩进一个人、一个现场、一个短周期里完成。

这不只是效率的提升，它改变的是软件交付的底层逻辑——从”产品找市场”变成了”工程师找场景”，方向是反的。

你可以把它理解成 AI 时代的敏捷极限形态。传统敏捷是在团队内部压缩反馈周期，FDE 直接把这个边界延伸到了客户工位上。

五、这件事对 AI 产品公司意味着什么

OpenAI 和 Anthropic 在大量招 FDE，这本身就挺值得想一想。

这两家公司卖的是全世界最强的 AI。按道理，他们的产品应该越来越”自助式”——用户自己接入，自己调，不需要人来手把手。但他们偏偏在往反方向走。

我的理解是：他们已经意识到，AI 软件公司的竞争，最终会落在”谁能让 AI 在你的具体场景里真的好用“这件事上。而这件事，短期内没有办法完全靠产品自动化解决。

所以，他们在用 FDE 这种人力密集的方式，建立竞争对手短期内复制不了的场景适配能力。Palantir 二十年前就在做这件事，只是当时没有人叫它 FDE。现在 AI 让每个行业都面临”Agent 落地”的问题，这个模式才真正变得通用。

一个反直觉的商业结论

FDE 是人力密集型工作，成本显然比卖 SaaS 席位高。但 Palantir 作为重度依赖 FDE 的公司，客户留存率和净收入留存率长期维持在行业高位。原因是：

客户采购的不是一个软件工具，而是把自己的业务知识编码进了一个系统里。这个过程一旦完成，迁移成本极高——不是因为功能绑定，而是因为知识绑定。

换句话说，FDE 建立的不是功能壁垒，是知识壁垒。而知识壁垒，比任何技术护城河都更难被复制。

六、结语

那些失败的 AI 项目，技术本身往往没什么大问题。模型够好，文档也备了，Prompt 也认真写了。

但有一个问题，从来没有人认真回答过：

谁来做知识的桥接？

谁来坐在业务专家旁边，把那套说不清楚的直觉，一点一点转化成 AI 能理解的东西？

这个问题，不是更好的模型能解决的，也不是更详细的 SOP 能解决的。它需要一个既懂技术、又能进入业务现场、还有能力把两件事连起来的人。

不同角色的人，在这件事上能做什么

• 在甲方做 AI 落地的：你们公司内部，可能已经有一个”天然的 FDE”——那个同时懂业务又会用 AI 工具的人。找到他，给他时间和空间去现场待着，比继续购买新的 AI 工具有效得多。
• 在乙方卖 AI 方案的：你的竞争优势不在于模型有多强，而在于你对客户场景的理解有多深。FDE 能力，是你和”直接调 API 的竞争对手”之间最真实的护城河。
• 在产品团队做 AI 产品的：下次用户调研，别只看需求文档和访谈记录。去旁观用户实际操作一遍——那些”手册里没有的边界情况”和”默默绕过去的规则”，才是真正的产品机会所在。

FDE 不是一个新岗位，它是 AI 落地这件事本身的必要条件。

AI 落地的能力上限，由模型决定。但落地的下限，由知识桥接的质量决定。

找到那个人，或者成为那个人——比换一个更贵的模型，有效得多。