模型更强以后，工程工作移到了哪里

Het Trivedi 在回顾自己 2024 年 1 月加入 Baseten 后的头六个月时，写到一组比“模型够不够聪明”更贴近日常工作的问题：客户需要把模型运行起来，达到响应速度、处理能力和成本要求，并让真实请求可靠地通过系统。模型优化之后，团队还要与客户共同测试，交付后继续支持交接。¹

响应速度，是用户要等多久。处理能力，是同一段时间能接住多少请求。成本则决定一项功能能否持续提供。一段令人印象深刻的演示，可能还没有同时回答这三个问题。

这段个人经历来自一家帮助客户运行 AI 模型的平台企业。它不能代表所有 FDE 的一天，却很适合作为 AI 时代的入口：新的模型能力提供了更多可以尝试的事情，企业仍然需要把其中一件变成可持续的业务。工程师就在这两者之间工作。

随后的公开材料把类似需求放到了更大的组织尺度上。到 2026 年，OpenAI、Anthropic、AWS、Microsoft 等公司宣布或描述了面向企业的工程与交付安排。读这些公告，容易形成一个顺口的结论：模型越强，就越需要 FDE。这个说法仍然太快。模型进步可以消除一些工作，也可以使另一些工作第一次值得投入；岗位需求取决于企业接下来要做什么，以及谁有能力把它做好。

要理解这轮变化，需要把技术问题、组织能力与供应商的商业选择放在一起看。

一个模型，进入三种不同的工作

先用一个教学情境比较。某企业希望利用同一种模型，帮助员工处理文字资料。以下三种安排不是任何真实客户的项目实录。

第一种安排是给员工一个通用工具，由人选择资料、提出问题，再检查输出。这时，人承担了不少系统没有承担的工作：判断资料是否适合上传，辨别答案是否可用，决定下一步怎样行动。如果任务风险和使用范围允许，成熟工具加简明培训可能已经足够。

第二种安排是把模型接到企业自己的资料库。用户希望直接提出问题，不再手动寻找每一份资料。于是，团队要知道系统能够检索什么、不同员工可以看到什么、资料是否过期，以及答案能否回到出处。模型可以帮助理解问题，但资料的实际分布和授权关系仍然要由系统提供。

第三种安排进一步允许系统行动，例如根据核准的请求更新一条业务记录。此时，一次错误不再只是屏幕上出现一句不准确的话，还可能改变后续工作。团队需要定义哪些修改可以直接执行、哪些需要人确认，失败之后怎样重试，以及重复执行会不会造成第二次修改。

三种安排可以使用相同模型，工程工作却大不相同。它们的差别来自系统取得了什么资料、接入了哪些流程、获得了哪些行动权限。不能只凭一次模型测试，就推定后一种安排已经同样可靠。

这个比较也说明，为什么一些企业会增加面向现场的工程投入。不是每一道技术困难都变难了，而是企业把目标从“帮一个人写点东西”推向“承担一段持续运行的工作”。原来由人临时补齐的判断，需要被看见，部分可以做成软件，部分应继续保留给人。

反过来，如果目标只是第一种安排，把一支昂贵的 FDE 团队放进去未必合算。岗位名称不能替企业决定投入强度。应先辨认那段工作，才知道缺的是使用培训、成熟实施，还是需要与供应商共同探索的新能力。

Baseten：客户已经很懂技术，仍然需要一起建设

Baseten 的 FDE 负责人 Vlad Shulman 在一篇标注最后更新于 2025 年 6 月 11 日的文章中，说明团队位于工程组织内，与客户工程师直接合作，也参与核心产品建设。文中同时指出，自助平台能够支持一部分客户自行部署；需要贴近协作的，是那些面对前沿模型、严格性能要求和快速变化需求的客户。²

这个安排值得注意，因为它没有把客户描述成等待技术普及的人。客户可能拥有很强的工程团队，却仍需要供应商的帮助。难点可能位于产品与新用途相遇的地方：客户知道自己的用户需要多快的响应，供应商更了解平台内部有哪些改进空间，双方都需要对方才能作出较好的选择。

“推理”是这里常用的技术词，意思是让已经训练好的模型处理输入并产生结果。对经营者来说，可以先把它理解为模型提供服务的过程。它不只发生一次，而要在真实请求持续到来时保持可用。一次运行需要多少计算资源、能否及时响应、资源不足时怎样处理，都会进入工程决策。

想象一个教学比较：某项文字整理工作可以等待稍长时间，另一项即时交互则不能让用户一直等着。即使两者对答案质量的要求相近，也未必应采用同一套运行安排。追求最短等待时间可能增加资源投入，过度压低成本又可能使高峰时的体验变差。工程师必须先弄清哪项约束最重要，不能只追一个技术排行榜数字。

Trivedi 描述的做法包括缓存模型权重，以减少服务刚启动时的等待；权重是模型运行要装载的参数，“冷启动”就是服务尚未准备好、必须先完成这些加载的时刻。优化后，工程人员与客户共同测试，再转入交接支持。¹ 这段材料没有公开一个具名客户的完整指标，但已把劳动落到模型运行的具体环节。

它也给出了一个能够检验的解释：若用户等待主要花在模型准备阶段，改变加载和缓存安排才可能有效；若等待来自客户自己系统的排队，再快的模型加载也不会消除那段队列。FDE 的价值需要来自查清这两段等待，并能调动对应的工程能力。仅仅更熟悉最新模型名称，并不能完成这个判断。

这也解释了为什么 Baseten 把 FDE 放在工程组织内。但这是它根据产品与客户条件作出的选择，不能直接变成其他公司的组织规定。同一篇管理回顾也承认，一些需求更适合技术客户经理或实施团队。² 需要定期咨询建议，与需要共同推进产品能力，是两种可以分别安排的工作。

供应商在购买不同的交付能力

截至本书资料截止日，面向客户的工程已经不只是一个岗位设计。下列公开安排中，能够核定日期的公告集中于2026年；AWS页面未注明可核的公告日期，不能据访问时间补成同年的事件。模型公司、云平台与服务伙伴选择了不同的组织办法。

系统集成，是让原本分开的软件与数据配合完成工作。把它与模型研发分开，便能理解为什么这些安排需要伙伴。2026年3月18日，Accenture 与 Microsoft 公布 FDE 业务实践，分别强调平台技术与流程、行业、规模交付的配合。⁸ 同一伙伴可以进入多项安排，所以不能把公告人数相加当成全球独立人力。

这些记录能证明供应商扩大了交付投入，不能单独证明企业整体对 FDE 的需求增长了多少。它们首先是供给侧的选择：有的增加深技术协作，有的补日常实施资源，有的加强销售渠道。要解释这轮变化，必须把公告放回它准备解决的缺口，而不是按金额排队。

功能变得可以调用，实施工作会减少哪一部分

还有一种变化发生在产品本身。Salesforce 于2026年4月15日介绍 Headless 360，提出让 Agent 通过接口和工具调用平台能力。Agent 在这里指能调用软件工具、推进任务的 AI 程序。“无头”则指不必先经过原来的操作界面，并不表示业务规则和权限消失。同一公告仍把审批链、共享规则与权限列为底层条件。⁹

功能范围还要继续往下核对。其7月开发者文章将 Headless 360 MCP Server 列为测试版，说明首期约一百项技能大多面向管理员的系统设置；调用以已认证用户的身份执行，原有访问限制继续适用。MCP 可以先理解为 Agent 寻找和调用外部工具的一套连接约定。4月的平台方向与7月这个具体服务的测试状态，不能合成“所有业务已经自动运行”。¹⁰

对于现场工程，这意味着某些原本需要逐个界面操作、另写连接代码的工作有机会减少。但团队仍须判断：应该用哪个身份，允许改哪些记录，现成操作是否覆盖本企业的例外。若这些都已由产品满足，就应缩小定制范围；若普通员工的任务只能借管理员的广泛权限完成，接口可用了，交付问题仍未解决。产品进步改变的是工作的分配，而非给每个调用自动授予业务上的正当性。

同样靠近客户，解决的短缺可能相反

Baseten 的材料提供了一种情形：客户很懂技术，需要供应商一起处理前沿性能与产品问题。Anthropic 的新业务公告则把另一类客户放在中心：公司认为，不少中型企业缺少建设和运行部署所需的内部资源。⁵ 前者需要技术能力之间的深入合作，后者还需要弥补执行能力。这两个需求都可能推动贴近客户的工程工作，却不对应完全相同的团队。

对能力很强的客户，外部工程师最有价值的部分，可能是能否深入供应商产品、找到某个性能问题的原因，并把改进接回核心工程。若他们只能转发文档或召开协调会，客户得到的增量可能有限。

对内部资源不足的客户，困难可能更靠前：谁能把工作拆清，整理连接，安排运行和维护？派来一名只愿意处理最难技术问题的工程师，也可能留下大量无人承接的普通工作。此时，拥有行业和实施能力的团队，与尖端模型知识同样重要。

这里可以再分清三种组织安排。供应商直属团队，更容易沿自己的产品组织寻找答案；专业服务伙伴，可能更熟悉跨部门改造与不同系统；客户内部团队，则掌握长期责任与每天发生的变化。这些都是需要结合具体人员和项目验证的潜在优势，不是根据公司类型就可以自动兑现的能力。

最理想的分工未必是把其中一种做得无限大。某个产品问题由直属工程师解决，数据与流程改造由伙伴和客户共同完成，日常操作逐步交回内部团队，可能比让任何一方包办都更适合。相应代价是交接变多：必须清楚记录谁负责哪一段，避免“大家都参与”最后变成“谁也不承担”。

这种比较也修正了早期讨论中常见的两分法：产品厂商负责技术，咨询公司只负责建议。2026 年公告中出现的，恰恰是模型技术、工程、流程和经营能力的重新组合。怎样组合仍要看交付，不能仅靠联盟名称判断。

工程介入越深，客户最终得到什么

Cohere 的工程师区分过两种依赖：选择平台带来的迁移成本，与客户不掌握运行知识造成的日常依赖。其主张是共同建设、培训与测试，而非把所有问题永久留给外部人员。¹¹ 这给前述组织扩张提供了另一种检查：供应商投入增加之后，客户是否更能改变自己的系统？

对于 Baseten 材料里的技术客户，答案可能体现为客户能自行部署和观察模型、遇到新的平台限制再共同工程；对于缺少内部人员的企业，则可能需要明确购买长期运行服务。两种关系都能成立，价格与职责却不应混为一谈。把第二种合同讲成“客户已经独立”，会在支持结束时留下无人承担的工作。

交接的具体验证留给第18章 采用与接手。这里先把它纳入需求判断：需要一次性解决的产品缺口、需要长期购买的服务，以及客户准备内部掌握的能力，是三类不同采购。名称相同的 FDE 团队，不一定能够覆盖三类要求。

真正的需求，不能只由卖方证明

前面的解释把重点放在真实工程需求上。但另一种解释同样有力：当企业开始为 AI 分配预算，供应商希望扩大客户关系、促进自家平台采用，并通过服务能力进入更多业务。设立团队、联盟和新公司，也可能是分销与经营安排的变化。

这不必与解决问题相冲突。帮助客户把系统运行起来，确实可能增加平台收入；客户因此获得价值，供应商也能获得回报。需要检验的是两者是否长期一致。例如，一次合理的技术建议，是否允许客户缩小项目、选择较简单的产品，甚至决定暂时不做？如果团队只在扩大使用时才被认为成功，就可能低估这些选择。

因此，不能由“多家公司宣布 FDE”直接推出“所有企业都需要 FDE”。这些材料来自供应商，能够说明它们怎样组织资源、对市场作出何种判断；它们不是企业总体需求调查。不同公告还混合了既有能力、新组织、未来投资和合作目标，必须逐项读清。

反方向的事实也值得保留。英国政府在 2025 年决定不再继续开发 Redbox，一项理由正是商业工具已经进入既有系统，内部积累则转用于其他工作。英国：公共问责会细看这个公共部门记录。¹² 它不是 FDE 失败案例，却足以反驳“模型能力越强，定制工程只会越来越多”这种单向解释。

因此，这轮变化至少有两个相反方向：新能力打开过去做不到的任务，增加探索性工程；成熟功能覆盖已有任务，减少定制的必要。岗位会怎样变化，要看前一种新增工作能否抵过后一种消失的工作。现有公告不足以给这两个量做总账。

一个实用的比较方法，是把 FDE 方案与一个同样认真设计的替代方案放在一起：若由客户内部团队、成熟产品和实施伙伴完成这段工作，哪些事情仍然解决不了？若回答只是“缺少更受欢迎的职位名称”，没有必要改变组织；若回答是产品缺口得不到处理、关键技术决策缺少信息，或者跨组织问题长期无人推进，就有了更具体的投入理由。

判断也应该能够随技术变化而变化。某类工作今天需要密集工程协作，后来可能成为标准功能；今天可用的固定方案，明天也可能因新的任务范围而不够用。一个有价值的 FDE 组织应帮助辨认这种变化，而不是必须证明自己的介入永远不可替代。

从岗位热度，回到工作本身

这一轮公开材料支持的，是一个有条件的回答：当企业把 AI 用到更复杂、持续运行的工作时，模型之外仍有数据、系统、权限、性能和组织采用需要建设；有些问题适合由贴近客户、又能调动供应商工程能力的团队解决。

它不要求每家企业都先设立 FDE，也不意味着客户可以把内部责任全部交出去。对准备采购的人，重要的是自己缺哪段能力；对准备设立团队的人，重要的是让工程师有权做什么、经验怎样进入产品；对准备进入这个职业的人，重要的是岗位承诺与实际工作是否相符。

回到 Trivedi 描述的任务，客户要的不是一条更漂亮的职位说明，而是模型在所需速度、容量和成本下可靠工作。把这个结果放大到整家企业，才会看见各种组织选择的必要性与代价。完成组织与经营判断之后，工程章节将沿着需求、数据、运行、评估和交接的工作顺序，借助不同真实案例与明确标出的教学情境，看看这些承诺怎样变成每天可以检查的动作。