一年前多一点，我和一位在发明"前置部署"这个词的公司里做了十年相关工作的人打了一小时电话。过去十二个月里，我也以不同形式与一些正在构建前置部署引擎的人合作过。我仍然觉得，没有任何内容能完全说清楚前置部署到底包含什么。
我和朋友聊的时候，问了他那个著名的"发现过程"到底是怎么运作的。答案说起来有点令人尴尬地"物理化"，至少在你只从表面看事情的时候是这样。你飞过去，花两天时间见所有和这个问题相关的人。ERP 经理会给你上一堂关于采购订单的理论课，然后带你到车间去看看理论漏掉了什么。接着，你花三周时间，每天问他们一个问题，同时把数据接起来。我问他有没有什么公式。他说，公式就是尽可能多地花时间在懂行的人身上。做了十年，这部分从来没变过。
但如果你不深入挖掘，这可能会产生误导。是的，他们花了很多时间和客户在一起。然而，优秀的前置部署引擎会提前构建模型。出色的部署工程师和部署策略师明白他们不可能什么都懂，但他们能非常快速地构建东西并和客户一起迭代。第一个工作流是眼前的目标。本体论被用作一种工具，逐步将这个工具扩展成一个操作系统。优秀的前置部署引擎之所以出色，是因为大量的背景信息来自团队、来自领域专家，他们甚至在第一次见客户之前，就在很大程度上把这些信息缝合在一起了。这部分能力是随着时间推移而提升的，也是某些引擎能产生复利、而另一些不能的真正原因。
我立刻想到了两个问题。如果你没关注过优秀的前置部署是什么样子，你可能也会有这些问题，所以我建议你继续读下去。
我的第一个想法是：当你对客户的工作流一无所知时，会发生什么？你会从大量的访谈开始，对吧？ 我朋友说不是，因为没人喜欢被访谈，但他分享了一个故事。他的团队曾为一家物流公司构建了一个路由引擎，这家公司的调度员依靠手动判断和查看地图、距离、垃圾填埋场位置以及其他运营约束条件来分配每日工单给司机或路线。我朋友构建了一个工具，能给调度员提供建议，但第一个问题是调度员经常凭直觉拒绝建议，而且又说不清楚为什么。为了解决这个问题，他的团队必须展示出所有可能的分配组合，然后利用这种可见性来比较人类决策和模拟结果。这是第一次有人把所有组合都映射到屏幕上，所以也是第一次大家有机会反思：自己凭直觉做的决定，到底有没有大规模数据的支撑。这让物流公司的团队能够审计工作流本身，理解流程逻辑是否正确，并优化数字孪生，使其更贴合业务的实际运作方式。他们也喜欢这个过程，因为它从来不像访谈，而是第一次让他们能在一个项目上看到所有拼图碎片。
我的第二个想法是：Agent 的加入，和几年前相比，会如何改变整个流程？ 我朋友回答说，这简单的意味着我们可以用 Agent 开发得更快，并且在"部落知识"层面拥有更多背景信息，但这只是拼图的一部分。他说，在他们的 FDE（前端部署引擎）模式中，这些试点项目的"魔法配方"并没有什么爱因斯坦级别的奥秘。在某些情况下，即便是现在，他们在做试点项目时，也只是在倾听步骤和结果，进行动词映射，然后给客户一支五人团队，作为他们的专属工程师。这些工程师把所有东西都编码化，然后他们就可以"消失"，客户可以继续使用这个解决方案。Agent 的作用在于，它们加速并深化了编码化过程，使其更容易整合来自客户系统各处的更多背景信息和部落知识。Agent 已经成为一种超越直接用户反馈的手段，转而拉取历史和运营背景信息，比如邮件、销售流程变更、Salesforce 等系统中的状态变化，以及组织过去运作的其他痕迹。这使得能够更丰富地建模客户工作流，连接分散的知识碎片，并构建不仅能通过数字孪生来表现业务，还能帮助自动化或支持目前由人工做出的决策的系统。
我从和他的通话记录里摘录了几段。
所以，所以我们的开始方式总是聚焦于快速实现价值。我们并不总是遵循一个程序化的方法，比如：好，我们先做本体论，然后在上层构建应用，然后去见用户。不，在某些方面我们会遵循，但在其他方面，我们只是问客户：'我们能为你构建的最大价值点是什么？'或者'我们现在能给你带来的最大影响是什么？'请你向我们解释你业务中的问题，以及你认为我们能解决的问题。
一旦客户分享完，我们就会回到绘图板，说：好，我们先切一个本体论的第一版，再在一周内构建一个应用的第一版，然后测试一下。所以这非常像，你知道的，就像一个初创公司是怎么搭建起来的。我们经常发现，他们可能会提出一个用例的想法，但在他们说的过程中，我们会发现另一个完全潜在的用例，我们可以直接解决。然后我们就会去构建那个，即使他们原本以为自己需要的是别的东西。归根结底，我们努力调整，去解决他们最需要解决的那个最大的问题。
我们会快速为那个东西建点什么，并在本体论中构建五个对象。如果我们做的是和 ERP 系统（可能非常复杂）相关的事情，即使在完成集成之后，我们也会每周找那个 ERP 专家进行几次一小时的密集讨论，或者半小时的临时会议。然后，一旦我们在那里证明了自己，就会寻找第二个、第三个、第四个用例，直到可以为他们的整个公司构建一个企业级操作系统。
我们通常以现场的形式来做这件事。我们会飞过去，说：好，给我们两天时间。我们会见所有利益相关者，要么大家一起，要么一对一见。在很多情况下，当人们很忙时，我们就坐在他们旁边，试着理解他们的销售流程或客户互动方式。我们会试着从他们的角度理解正在发生的事情，而且我们不会压缩与客户在一起的时间。实际上，我们会更多地投入其中，这是十年来从未改变的事情。有时候，我们会花整整几周时间与客户在一起。我们从未试图摆脱这一点，或让我们的平台在发现阶段完全自动化。
讨论中的一个核心观点是，编码化是通过迭代实现的，而不是通过繁重的文档工作。团队直接在代码中为公司构建一个"数字孪生"，利用数据集成、运营背景信息和领域专家的输入，来体现组织在实际中的运作方式。但光有数据模型是不够的。更难也更有价值的部分是业务逻辑——理解什么地方需要干预，应该推荐什么行动，以及经验丰富的操作者实际是如何做决策的。这一切不仅仅是把信息呈现出来，更是帮助用户评估权衡、验证工作流，并最终将决策支持编码到产品本身中。
我后面的谈话更深入地探讨了这项工作是如何不依赖于从一开始就嵌入深度领域专家的。其预期是，前置部署工程师能够进入陌生环境，快速学习，并通过快速交付有用的系统来建立信誉。早期的合作通常以一个简短的"训练营"开始，辅以预先构建的原型和样本数据，旨在快速展示价值，并赢得深入部署的权利。从那里开始，关系可以从单个用例扩展到为客户构建一个更广泛的操作系统，其长期目标是如此有效地编码化工作流，以至于团队最终可以退出，而客户能继续使用这个解决方案。
对于正在构建的新项目来说，这是一个高度相关的剧本。这就是前置部署。其他的一切都只是点缀。
复利法则
前置部署成本高昂，在毛利率上见效慢，而且难以进行整齐的规划。创始人会有这种感觉，并开始质疑这份努力是否匹配得上最终的成果。最终，某个领导者会大声说出来："我们付出了两倍的努力，只得到了两倍的回报。"
如果这句话暗示前置部署不是正确的模式，那么对于某些行业来说，这是一个危险信号。我理解创始人的不耐烦，因为我自己也当过创始人，但天真和急躁之间只有一线之隔。对于那些在前置部署引擎下运作得更好的业务来说，任何用乘法来做这个计算的人都没有理解这份工作的本质。如果两倍的努力只换来两倍的成果，那你雇佣的其实是顾问，只是给他们贴上了工程师的标签。你将永远需要随着收入增长而同步增加人手，你的利润率永远无法提升，你真正建立的东西，说白了就是一个写代码或提供支持的人员外包公司。那些不清楚自己在构建什么的人，几乎最终都会得到平庸的结果，而这种混淆对你来说只会产生负复利。
前置部署只有在数学上产生"弯曲"时才有意义。第一次部署可以允许是丑陋的、手工的、在经济上站不住脚的。它的任务是"教导"。第二次部署必须更便宜，因为第一次部署留下了一个模板、一个集成、一个文档化的模式、一个平台组件。到了第十次部署，第一个团队手工完成的大部分工作应该通过配置来完成，而人类应该向上一个层次，去解决那些在客户眼中一年前甚至还不存在的问题。在第一个月和第七个月之间，这两个数字之间的距离就是复利，而这条曲线才是你资助一个前置部署团队时真正购买的东西。复利才是全部意义所在。如果自称做前置部署，却没有一个能产生复利的引擎，那纯粹是愚蠢。
软件工程师和前置部署工程师的主要区别在于，SWE 花在编写代码上的时间，大多是维护、支持或按路线图构建东西，而 FDE 花时间发现那些通常不在路线图上、但能解锁客户价值的东西，然后部署它，并且当模式在不同客户间重复出现时，将其传递给产品。
每个人都在用，但几乎没人真正理解这个词
这个概念有一个特定的起源。二十年前，一位创始人问为什么好的法国餐厅很出色，结果落到了服务员身上。在一家好餐厅里，服务员是厨房的一部分，所以当他们推荐菜品时，那是厨房在说话。Palantir 构建了这个概念的工程版本，并赋予了这个角色一个军事化的名字，因为它的客户是军方。这个名字赋予了现场工作应有的地位，这是理所当然的。它的报酬如此之高，以至于二十年后，每个人都想要这个名字，但我不确定有多少人真正理解了这份工作。
在某种程度上，前置部署团队必须做创始人在 0-1 阶段必须做的事情。你经常需要去发现你能交付什么，不仅能提升一个虚荣指标，还能真正帮助客户发展他们的业务。这是我朋友谈话中的另一个真实例子。他的团队受雇于一家电动汽车充电器制造商，他们希望将产量提高大约 10 倍。这就是任务简报。你能猜出结果吗？因为那肯定不是一份策略报告。这家公司的目标表面上看很简单：将电动汽车充电器产量提高 10 倍。而前置部署团队实际做的是：到现场，从业务的多个层面去了解运营情况。他们花时间与 ERP 负责人在一起，了解记录系统、采购订单、工单、供应和需求。然后他们去了车间，看看生产实际上是如何进行的。同时，他们与高管交谈，了解问题的战略版本，因为一线操作员说的"错误"或"紧急"的事情，并不总是完全符合领导层认为最重要的约束条件。因此，这项工作（至少从会议上的发言来看）不是直接去建一条新的生产线。而是构建一个运营的数字孪生，然后识别出软件可以在工作流中的什么地方进行干预，例如，围绕关键部件短缺、采购订单时机、安全库存以及其他运营决策等问题。最终描述的成果是一个能够更早地发现风险并推荐行动的系统，而不是对制造本身进行物理改变。我希望这解释了我所说的"前创始人可以成为出色的前置部署人员"是什么意思。
看看今天（工作经历，而不是职位描述），你会发现，有些工程师在客户的系统中编写生产代码，并负责上线后的一切，包括支持。其余的都是些销售工程师，他们有一张更好听的名片，主要靠演示来评判，再加上一长串内部自动化岗位，只是因为这个词很时髦就借用了。关于"前置部署"是什么，还有一些更糟糕的混淆。通过几百次领域访谈来运作一个专家网络，这是研究，但不是前置部署。当一家私募股权公司收购公司并派去一个转型团队时，这很有用，有时甚至很出色，但不一定是前置部署。我这么说，是因为在这两种活动中，没有人拥有我所称的"工作闭环"。
"工作闭环"是整个学科赖以计量的单位。不是交付了一个功能，也不是解决了一个工单。而是客户的一项工作，从令人担忧的站立状态，一直推到没人再需要操心为止。合同签署是那些容易混淆的工种之间的分界线。销售工程师的工作止于合同签署。前置部署团队的工作始于合同签署，因为同意某件事应该能行得通，和它真正行得通，是两码事。如果一个人背着销售指标，你看到的是销售。如果一个人在项目上线三个月后还在客户的日志里，你看到的是前置部署。一家销售营销产品的公司会派销售工程师去签单、部署和配置。一个真正的 FDE 可能会得出这样的结论：产品支持的所有工作流都对客户没有帮助，而一些全新的东西能直接影响到营收或利润底线，然后他们就构建那个工作流。这需要精通"妈妈测试"（读读那本书），需要理解客户关心的不是你的功能，而是他们如何能更好地做生意，需要理解你的产品能做什么，并以快速迭代的方式交付，以便你能在真实的工作流中和客户一起迭代。
所以，这就是我会贴在墙上的定义：前置部署，就是站在你交付的东西和客户实际需要的东西之间的差距里，用你自己的双手，在客户的世界里，去弥合这个差距，并且在这个过程中，让你的产品学会下次自己来弥合。
这句话的后半部分，几乎是所有人都失败的地方。
为什么这个概念突然无处不在
七十年来，软件帮助人们完成工作。现在，它开始自己完成工作了。这颠覆了一个隐藏的假设。一个工具可以容忍被缓慢采用。但一个"工人"不行。当你开始销售结果而不是座位时，就必须有人去让这个结果在一个和你演示环境完全不同的公司里成为现实。
在过去两年里，模型不再是瓶颈。部署成了瓶颈。一项关于企业 AI 试点项目最常被引用的研究发现，大约 20 个项目中，有 19 个没有产生可衡量的 P&L 影响，而事后分析几乎从来不怪模型质量。问题出在软件从未学会工作流。文档化的流程有四个步骤。真实的流程有九个，而那缺失的五个步骤，存在一个女人的记忆里，在她多年前构建的个人追踪器里，以及在她和另一栋楼里的另一个女人交换的人情里。在更传统的行业中，工作运行在你们工程师出生之前就安装好的系统上，边缘地带靠传真机和电话维持着。这些东西没有一个有 API。在油田里，有人会把耳朵贴在钻机上，判断声音是否表示他们应该担心的事情。在从印度往美国运送鱿鱼的船上，中途在伦敦停靠，运费和价格是基于直觉、有限的天气数据，以及肉眼观察到的货物质量来决定的。部落知识是每家公司的承重层，但从来没有人为此发布过 SDK。过去十年工业平台的"坟场"用几十亿美元学到了这个教训。转型项目不会死在架构上，而是死在采用环节上。
钱已经注意到了这一点。微软投入了 25 亿美元和 6000 人，将专家嵌入到客户中。AWS 几周前也为此投入了 10 亿美元。OpenAI 和 Anthropic 各自成立了专门的部署公司，背后有世界上一些最大的投资者支持。你可以称之为时尚。但如此规模的资本很少是伪装。实验室们估算了自身的管道，发现买家从来不缺智力。买家缺的是"人手"。失败存在于最后一英里，而最后一英里正是护城河被挖掘的地方。我们花了 10 年时间在 LLM 上努力拼搏才走到今天。如果我们要让这些模型理解工作流和人类决策框架，可能需要花更多的时间。
为什么团队里需要一个商务人员
工程师存在，是因为差距需要用代码来弥合，在客户的架构上，针对客户的边缘情况，通常要在几天内完成。用户早上描述的东西，应该能在几天内（而不是几个季度）就在他们面前跑起来。这种速度，就是和那些目睹过三年转型项目只产出一堆幻灯片的人建立信任的方式。
商务人员存在，是因为部署中最难的问题不是技术问题，而假装技术能解决一切是技术团队失败的方式。在任何人自动化工作之前，必须有人找出实际的工作是什么。必须有人决定 20 个升级问题中哪三个最重要，谁的工作流是真正的瓶颈，哪个高管的沉默会扼杀采用，以及什么样的成果才能证明整个合作是值得的。必须有人擅长读懂客户什么时候在退缩，什么时候只是在说客套话。必须有人来运营企业 AI 中最微妙的接口——你的产品今天能做什么，和你承诺六个月后必然能实现什么之间的那个接口。我把部署策略师看作是公司的"期货部"。他们以关系能够承受的价格，卖出产品将要成为的样子，并确保这个头寸永远不会违约。高风险的交易是在这个"期货部"赢得的，而没有它，交易就会泡汤。
失败的形态会告诉你缺了哪个角色。如果交易停滞不前，因为产品无法在客户环境中运行，或者产品只支持其内部存在的工作流，这意味着你缺少工程师。如果工程师忙着交付客户要求的功能，但收入却没有随之增长，或者 FDE 已经打了 100 多个电话，但已签约的收入仍然远高于已实现的收入，或者存在大量不改进系统的定制化工作流孤岛，这意味着你缺少策略师。
在最好的团队中，这两个角色是模糊的，而这种模糊恰恰是重点。工程师培养了商业直觉，策略师学会了阅读数据模式，这样你得到的就是公司能雇佣到的最接近"创始人"的人才。前置部署，是每个创始人在组织架构图掩盖它之前，要花好几年时间做的事情：坐在客户的混乱之中，用身边的一切工具来闭环工作，让学到的东西重新定义产品。这个角色，就像是创始人拿着别人的期权表，过了一周他们的生活。这也是为什么这类团队培养创始人的速度，让大科技公司都感到汗颜。如果你在运营一个 FDE 小组，你应该从第一天就做好继任计划，因为很可能，十年后那些构建公司的创始人，都会是今天正在发生的前 FDE 人员。
如何判断你是否有真正的前置部署团队
你不能通过一张快照来判断一个前置部署团队，因为在任何一天，一个优秀的团队和一个虚假的团队看起来都一模一样：聪明的人飞到客户那里，上演英雄般的交付。五次检查能暴露真相。
#1 每个客户的投入。一个去年服务了五个客户、今年仍然只服务五个客户的团队，没有产生任何复利。一个现在能服务十五个客户的团队，说明它正在哺育一个能够吸收现场所学到的知识的产品。每服务一个客户，你的团队内部都应该培养出一个领域专家。
#2 工作的新颖性。如果第四次部署是第三次的重复，那就没有人负责从现场到平台的管道。必须有人负责去发现跨账户的重复模式，因为重复，就是路线图自己在写自己。
#3 同一细分领域第二次部署的形态。如果第十个客户的花费和第一个客户一样多，那你不是在规模化一个产品，你是在连锁化一个项目。
#4 汇报线。如果汇报线在产品或工程部门内，反馈循环可以闭合。如果汇报线在销售或服务部门孤岛内，学到的经验只会留在没人读的出差报告里，团队会悄无声息地变成利润中心的负担。
#5 客户自己的记分牌。活动只是表象。使用数据可能看起来很棒，但下游没有任何改善。唯一能经得起 CFO 审视的衡量标准，是一个由客户帮助编写的评估，基于他们的数据，对他们的成果进行评分，从第一周就开始构建并公开追踪。除此之外，还要保留一个人类测试。当客户的业务中发生了与你产品无关的故障时，他们第一个电话打给的是你吗？每一个仪表盘，本质上都是在试图模拟那个电话。
还要小心一种黑暗模式，因为它现在无处不在。在一些公司里，前置部署团队不是一个学习引擎，而是一个掩盖器。产品本身不太好用，所以每个缺口都安排了一个人。因为这个人是英雄，所以缺口永远无法进入路线图。因为缺口永远无法进入路线图，产品永远无法改进，所以这个人也永远无法离开。产品部门没有压力，因为现场部门一直在兜底。现场部门什么也没写下来，因为他们忙着救火。发票一直在寄出，因为客户确实得到了服务。这个机器是平衡的，而平衡本身就是问题。公司在这种状态下可以活好几年，现场人员数量的增长和客户数量完全同步，并称之为"前置部署"。这不是。这是按月收费的、产品缺失的替代品。这也是为什么这么多身居这些职位的有才华的人会觉得自己在失败。他们被雇佣来产生复利，却被安排去掩盖问题。
每个阶段看起来是什么样
<code-segment id="end" lang="text">
</code-segment>
早期阶段，不要雇佣它，而是成为它。创始人就是前向部署团队，而你用稀缺的理解力能做的最糟糕的事，就是把它外包出去。亲自去参加那两天的出差。和调度员坐在一起。当你最终招聘时，招那些能让你更快完成工作的人，而不是那些站在你和客户之间的人。
成长阶段是前向部署最容易被人误解的时候，因为从外部看，这像是在放慢脚步。你的董事会看着工程师们在一个客户身上花数周时间，而竞争对手每周都在发布新功能。财务账目让情况更糟。部署被计入收入成本，尽管它的工作性质更像研发，所以你学得越好，账面上看起来就越糟。在不撒谎的前提下，同时接受这两个事实。在账本里，它是成本；在战略上，它是研究。解决办法不是讲个故事，而是设置护栏，迫使研究产生回报。为每个项目设定时间限制。将每个项目与一个明确的业务成果挂钩。每季度收割一次，意思是每个季度，团队手工搭建的东西都要变成平台自动完成的事情。我们以后会把它产品化这句话是扼杀公司在这个阶段的元凶，因为以后没有负责人。
规模化后，问题就变了。你有数百个客户支付数百万美元，并且你已经拥有解决方案顾问、实施团队、托管服务、客户经理、客户成功团队。这个阶段的领导者真的不知道前向部署团队应该放在哪里，所以它被当作第四层支持强加上去，然后死于工单量。答案是：每个现有职能都有一套操作手册，而前向部署团队只存在于没有操作手册的地方。那十个最雄心勃勃的客户。那个新垂直领域。那个整个行业都说无法自动化、但你觉得只有你能自动化的工作流程。它向产品汇报，其使命是让自身的工作变得多余，并将每个解决的模式交给运行操作手册的团队，这样操作手册才能保持活力。Uber 的版本很有启发性。他们把最懂 AI 的工程师与来自财务、法律和支持部门的领域专家配对，给每对两周时间，并且要求他们与工作流程的负责人并肩工作，而不是向对方展示。两天观摩，一天选择目标，第十天上线。十六个小组在两个月内重写了十六个职能，一份原本需要两天完成的报告现在只需十分钟。自动化的单元从来不是任务。它是工作流程，而工作流程只会在那些身处其中的人面前展现。
同样的工作，在不同行业穿着不同的外衣
在国防和政府领域，存在感就是产品。安全许可、隔离网络、你的笔记本电脑不能带出房间。在医疗健康领域，工作就是工作流程考古。真正的流程运行在使用了二十年的系统中，传真机和电话树仍然承载着例外情况，每个机构都运行着自己不成文的变体。一个认为流程是标准化的团队会浪费一年时间。在金融服务领域，客户购买的是合规下的判断力，交付物通常是一份监管机构可以阅读的评估报告，最深层的焦虑不是数据泄露，而是判断力泄露——他们最优秀人才的决策模式被引入别人的模型。在制造业和物流业，真相存在于现场，而约束条件是物理的，这就是为什么发现无法通过视频进行，且系统记录陈旧、明显复杂且经常与云断开连接。在消费品行业，反馈循环以天为单位，而不是季度，稀缺的技能是品味——知道品牌听起来该是什么样，以及机器什么时候该闭嘴。最新的领域是你自己的公司。同样的小组，部署到你自己的财务、法律和支持部门，因为 AI 能做什么与你组织实际做什么之间的差距，就在隔壁那栋楼里。
地形决定战术，战术可以协商，但顺序不可改变。与工作并肩，完成工作，反哺产品。
谁真正擅长这个
发明者 Palantir 仍然运行着最深度的版本，而人们忘记的细节是，这个模式出现在产品之前。一开始没有任何可配置的东西，只有一个赌注：如果你足够长时间地坐在破碎的机构里，产品就会显现出来。它们确实出现了，如今同一家公司运行着更短、更模板化的项目，因为一旦产品存在，复利就是信仰。
新一代最容易在客户服务代理公司中看到。Sierra 将其现场职能作为 Agent 工程师来运行，这个循环是刻意设计的。为一个客户解决问题，在公司内部推广有效的方法，然后将获胜者升级到平台，这样每个客户都能继承它们。当他们的工程师在数十次部署中了解到 Agent 何时应该停止重试并将客户转交给人工时，这种判断力变成了一个可复用的组件。然后他们构建了 Ghostwriter，一个可以进行构建的 Agent，它依赖于通话记录、标准操作流程和白板照片，运行在他们重新架构的平台之上，使得 Agent 可以直接操作它。投资 Sierra 在很大程度上，就是赌它的部署团队会不断发现别人没看到的工作流程。Decagon 走了系统路线，审计了其部署中那些没有理由定制的工作，将每个 Agent 背后的定制工程减少了 80%，然后公开说了心里话：交付，而不是产品，正在成为护城河。Ramp 的现场团队大量招聘前创始人，让他们面向从第一次通话到长期支持的整个客户生命周期，并培养一种习惯：在构建之前质疑需求，因为提出的要求通常是症状，而不是病因。
一旦你了解了形态，你会在每个严肃的垂直领域看到它。Harvey 将前执业律师嵌入律师事务所，证明部署人员不一定非要是工程师，只需要有责任感。在金融领域，Rogo 将近一半的员工是前银行家，他们被部署到他们曾经工作过的机构，而 Hebbia 则派工程师到全球最大的资产管理公司构建最后一公里。Abridge 正在与医院系统建立部署小组，因为将 AI 听写工具带给一万两千名临床医生不是安装，而是一场战役。HappyRobot 与货运经纪人合作，Gecko Robotics 在海军舰船上部署工程师，Applied Intuition 深入到全球大多数大型汽车制造商内部，Cursor（SpaceX）则运行着一个前向部署团队，将你工程师已经喜欢的工具接入银行和电信公司。
不同的形态，同一个物理定律。现场反馈工厂，否则就不是前向部署。
最有力的反对意见，因为它值得被认真对待
有一种观点认为，整个职业都是一种道歉。你被卖了一个会自己做饭的厨房，结果它带着一个厨师来了，住在你家里，花着你的钱，还带着供应商的加价，而且没有搬走日期。这个宣传要求你同时相信两件事：这台机器足够聪明，能替代你的烹饪；又足够无助，需要一个人时刻看管。如果产品需要一个常驻人类，那产品就没有完成。
认真对待这个观点，因为对许多供应商来说，这确实是真的。区分物种的测试，正是这篇文章一直在重复的那个。如果那个缺口的人类是永久性的，那么批评就赢了，你只是在租用一个补丁。如果那个缺口的人类是复利性的，以消除自身需求的方式完成工作，那么批评在第二次部署时就失效了。它没有看到的是，大部分工作从来都不是产品完成。而是上下文获取。那五个未记录的步骤，调度员未说出口的直觉，跨建筑的交易人情。没有哪个已完成的产品会自带这些，因为它们在每个公司里都不同。必须有人去获取它们。唯一重要的问题是，他们获取的东西是复利成资产，还是蒸发成发票。
未来走向
四个转变已经在进行中。
上下文成为资产。 部署团队在每个客户那里真正构建的是该公司如何运作的工作模型。本体论、数字孪生、谁决定什么以及为什么的地图。投资者已经开始称其为公司大脑，这个名称开始流行，因为每个公司都需要一个。其中很大一部分，比人们想象的要多，可以在任何人登机之前就通过引导完成，因为客户不断通过支持工单、通话记录、电子邮件、升级线程泄露自己的真相。从那里开始。但最深层的、人们无法言说的知识，仍然需要存在感和镜像工具，让内部人员审视自己的直觉，直到它变成逻辑。谁持有那张地图，谁就持有客户，这引出了每个 CEO 即将向每个 AI 供应商提出的问题。我租用智能，但谁拥有学习？如果一个共享模型吸收了市场中每个贷款人的信用判断，那么池中最敏锐的承销商就是在培训她的竞争对手，并为此付费。每个 CFO 都可以运行一个测试。明天在纸上换掉模型供应商，看看你教给系统的一切是否都随它出门。期待合同、团队，最终是公司，围绕一条线重新组织。租用智能，拥有学习。
Agent 加入团队。 前向部署的 Agent 已经以早期形式存在。入职 Agent 将一下午的集成工作压缩到几分钟。部署 Agent 在夜间阅读自己的记录，并提出改进自身技能的方案。看看这对人类角色做了什么。每一次手动干预不再是工作本身，而变成了训练信号，团队的职责也发生了逆转，从执行部署变成了运营进行部署的工厂。就像经理配置人员一样配置人员。像经理写评估一样写评估。更深的逆转在于用户是谁。产品正在被重新构建，以便 Agent 可以直接操作它们，并且客户那里的第一个发现问题正在悄然从你的团队需要什么变成你的 Agent 需要什么。同样的转变也在影响收入端，一个人带着一个 Agent 舰队现在就可以运行曾经需要一层楼的人才能完成的管道，售后软件也在重新自我定位，从工具变成拥有结果的承诺服务，今天是为留存服务，明天是为扩展服务。当你的客户的 Agent 开始与你的 Agent 谈判时，留在桌子两边的人类将只做两件循环无法独自完成的事：决定什么值得想要，并确认它确实发生了。
底价下降。 几年前需要五百万美元精英工程的部署，现在只需要几十万美元和一个敏锐的通才加上好的 Agent，而且价格还在下降。前向部署不再是财富 500 强的奢侈品，而变成了中型市场软件如何销售的方式。约束条件不再是工程供应，而是判断力供应。
职位消解。 每个严肃公司的工程师都在部分地成为前向部署人员。后端工程师参与客户电话。产品工程师根据通话记录发货。很快，面对客户的时间百分比将成为前向部署工程师和软件工程师之间的唯一区别，职位名称将不再假装不是。这带来了一个招聘启事上从未写明的警告。这份工作将建设者变成了外交官，而许多才华横溢的工程师选择建设，恰恰是因为满屋子陌生人会让他们精疲力竭。尊重内向者，不部署他们；尊重这个角色，永远不要用它来安置那些在工程上平庸的工程师。恰恰相反。这是你派去那些你信任他们能开创一番事业的人的地方。
公司里最古老的职位
抛开术语，前向部署就是创始人的原始姿态，在一个已经壮大到足以忘记它的公司里保持活力。坐在工作发生的地方。完成工作。让你学到的东西改变你构建的东西。每个经久不衰的公司都在它有名字之前就做到了这一点。大多数公司在他们负担得起不做的第一天就停止了。
所以真正的问题从来不是是否雇佣前向部署工程师。而是你是否愿意经营一家公司，让最接近现实的人拥有真正的权力，让努力以其斜率被评判，让在现场学到的东西不被允许在那里消亡。构建这样的公司，职位自然会各就各位。
你团队最近一次彻底完成的工作是什么，以至于客户不再去想它？上一次客户续约不是因为从你的产品套件中获得了价值，而是因为他们知道你会构建他们甚至不知道需要用来发展业务的东西，是什么时候？从那里开始计数。
