FDE模式企业AI智能体开发 | 驻场交付+灵活合作方案

说到FDE模式企业AI智能体开发，企业最关心的始终是它能不能真正落地、能不能对业务结果负责。企业采购AI能力时最常遇到的困境是：买SaaS平台，适配不了自己的流程；自己招团队做，半年过去还在POC阶段；找外包按人天做，钱花了却拿不到能用的东西。FDE模式企业AI智能体开发是针对这个困境演化出的第三种路径——由前置部署工程师带队进入客户现场，对业务结果而非工作量负责。与固定范围的项目制不同，FDE模式企业AI智能体开发在合作方式上高度灵活：驻场深度、团队规模、结算方式、知识产权归属都可以按项目阶段动态调整，这也是它在需求高度不确定的智能体项目上表现突出的原因。

一、为什么传统交付模式在智能体项目上集体失灵：FDE模式的现实动因

1.1需求不可预写：软件工程的基本假设被打破

过去三十年的软件工程方法论，无论是瀑布还是敏捷，都建立在一个前提上：需求可以被描述，并且描述可以被验证。用户能说清自己要什么，因为他们对软件的能力边界有基本认知——一个报销系统应该有什么功能，业务人员心里有数，参考同行的产品也能说出个大概。

智能体项目打破了这个前提。原因是大模型的输出是开放的、非确定性的，用户无法在看到实际结果之前准确描述”什么样的输出算好”。我们在项目启动会上反复遇到同一个场景：请业务负责人写出验收标准，写出来的通常是”回答要准确、要专业、要符合公司要求”这类无法验证的表述。而当系统第一版上线后，同一位负责人能在十分钟内指出二十条具体问题——他不是之前不想说，而是之前不知道能说什么。

这个特性决定了智能体项目无法用”先定需求、再报价、再开发”的传统流程。它需要一种允许需求持续演化、且演化成本可控的交付模式。FDE模式企业AI智能体开发的应对方式是把”需求确认”这件事从项目前期的一次性动作，变成贯穿全程的高频动作——每周甚至每天与业务专家过一遍badcase，让需求在真实的反馈中逐渐收敛。

1.2责任边界模糊：三方互相指责的死循环

智能体项目失败后的归因通常是混乱的。模型供应商说”是你的数据质量问题”，客户IT部门说”是供应商提示词写得不好”，业务部门说”这个东西根本不能用”。三方都有道理，也都无法证明，因为缺乏一个能把责任落到具体环节的度量体系。

这个死循环的根源在于传统交付模式中没有人对”端到端效果”负责。模型供应商只对模型API的可用性负责，外包开发只对功能点交付负责，客户IT只对系统集负责。中间的”效果”地带——模型在你的数据上、你的流程里、你的场景里表现如何——没有主体责任方。

FDE模式企业AI智能体开发的核心设计就是填补这个空白：由一个团队承担从数据、到提示词、到检索、到编排、到界面、到培训的完整链路责任，并且用可测量的业务指标验收。责任单点化之后，归因问题自然消失——不需要争论是谁的责任，因为只有一个责任方。这也是为什么FDE模式企业AI智能体开发的合同虽然谈判周期更长，但执行期的争议反而更少。

1.3知识工程的隐性工作量被严重低估

几乎所有首次做智能体项目的企业，都会低估知识工程的投入。管理层看到的是一个能回答问题的对话框，想象中的工作量是”接个API、写个提示词、上传文档”。实际执行时才发现：文档需要版面解析，扫描件需要OCR，历史版本需要去重，术语需要统一，冲突内容需要裁决，缺失知识需要专家补齐。

在一个中型企业的典型场景中，支撑一个业务Agent所需的知识工程工作量大致是：文档收集与清洗3到4周、结构化处理与切片策略调试3到5周、专家知识抽取4到6周、评测集构建2到3周。加起来12到18周，远超多数企业”6周上线”的心理预期。

更关键的是，这类工作无法远程高效完成。专家知识抽取需要面对面的深度访谈，术语统一需要拉着业务、IT、法务一起开会，冲突裁决需要找到能拍板的人。这些动作的共同特点是高沟通密度、强组织协调——正是远程交付最不擅长的部分，也是FDE驻场模式价值最集中的地方。

二、FDE模式企业AI智能体开发的核心概念与能力拆解

2.1FDE模式的三个结构性特征

这三个特征是相互支撑的，缺一不可。只做到”前置部署”而”不负责结果”，就退化成了高级人力外包，工程师没有动力主动优化；只承诺”结果负责”而”不前置部署”，供应商对隐性知识无从下手，最终只能靠加人堆时间；”能力复合”则决定了前两条能否落地——一个只能写代码的工程师，即使坐在客户现场，也无法完成知识抽取。

2.2团队的典型配置与角色分工

FDE模式企业AI智能体开发的团队配置与传统项目有显著不同，人数更少但角色更复合。首期单场景项目的标准配置是2到4人：1名资深FDE，承担方案设计、客户沟通、指标谈判和关键决策，要求具备5年以上企业级系统经验加上至少3个完整的智能体项目经历；1名全栈工程师，负责系统集成、编排逻辑、界面开发和部署；1名数据工程师（复杂场景配置），负责文档解析、数据治理、评测集构建；0.5名领域专家（按需要外部聘请或由客户指定），负责专业规则把关。

对比之下，传统外包项目的同等范围通常需要6到9人，因为角色分工更细、需要额外的项目经理和需求分析师做翻译工作。人数少带来的不只是成本优势，更重要的是沟通路径的缩短——4人团队的内部沟通路径是6条，9人团队是36条，这个差异在需要高频迭代的项目中会被放大。

2.3灵活合作的五个可调维度

FDE模式之所以被称为”灵活合作方案”，是因为它有五个维度可以按项目阶段和实际情况调整：

驻场深度可以从全驻场（每周4到5人天）调整到混合驻场（每周1到2人天）再到远程加定期到场（每月2到3人天）。典型节奏是首期全驻场4到6周攻坚，中期混合驻场4到8周迭代，运维期远程。

团队规模可以按月调整。攻坚期投入3人，灰度期减到2人，交接期减到1人加远程支持。这种弹性在传统人天合同中很难实现，因为人天合同通常锁定了人数和工期。

结算方式可以在人天、里程碑、效果对赌之间组合。常见的组合是：前期按人天或里程碑支付基础费用（占60%到75%），后期按业务指标支付效果费用（占25%到40%）。也可以按阶段切换——首期按人天降低双方风险，二期对指标有把握后转为按效付费。

知识产权归属可以分层约定。通常的建议是：代码、提示词、知识卡片、评测集、配置数据的知识产权归客户，而供应商保留通用方法论、框架代码和工具库的权利。这样既保障客户的资产安全，又不剥夺供应商复用基础能力的空间，后者是供应商愿意给出更优惠报价的前提之一。

合作期限可以是项目制，也可以是年度框架。对于计划连续推进多个场景的企业，年度框架更划算——通常能获得10%到20%的价格优惠，因为供应商可以平滑安排资源，避免人员闲置。

三、落地方法论：FDE模式企业AI智能体开发的六阶段实施步骤

3.1阶段划分与时间线

3.2每一步的输入、动作、产出与常见坑

场景评估阶段最关键的动作是基线测算，而基线测算必须基于真实工单的现场计时，不能采信管理层的估计。我们在多个项目中对比过两者，差距经常在40%以上——管理层倾向于低估简单任务耗时、高估复杂任务耗时，而真实分布往往是长尾的。另一个必须完成的动作是数据可得性体检，逐项确认四类资源：文档（是否在、什么格式、有无版本冲突）、系统数据（有无接口、权限怎么申请、字段口径是否清晰）、历史样例（能否导出、有无标注、覆盖度如何）、专家时间（谁能配合、每周能投入几小时）。四类资源中任何一类严重缺失，都应该换场景而不是硬上。

知识盘点阶段的核心是知识地图。把场景涉及的知识分成三类：显性文档类（手册、规范、历史案例）、系统数据类（结构化字段、交易记录）、隐性经验类（专家的判断直觉、约定俗成的做法）。经验比例大致是4:3:3，而第三类是驻场团队的核心攻坚对象，也是决定项目成败的关键。抽取隐性知识的有效方法是”出声思考法”——请专家在处理真实任务时边做边说出自己的想法，由FDE逐条记录并追问”为什么这里这样判断”。常见坑是采用问卷式访谈，得到的大多是标准化流程描述，抽不到真正的判断逻辑。

原型开发阶段要遵循”先通后优”的顺序。第一周的目标是跑通端到端最简链路，哪怕质量很差，只要能从输入走到输出即可。这样做的价值在于尽早暴露结构性问题：数据能不能拿到、接口稳不稳定、输出格式能不能被下游系统接受。我们见过太多项目在这上面翻车——团队花三周优化检索策略，最后发现客户的核心系统根本没有开放接口，所有优化归零。结构性问题确认无碍后，再进入逐环节优化，顺序建议是：切片策略→召回策略→重排序→提示词结构→工具调用→输出格式。

效果攻坚阶段的标准动作是每日评测加每日复盘。上午自动跑全量评测集，输出分数和错误清单；下午与业务专家一起逐条看错误，按”检索不到””检索到了但没用””推理错误””格式不符”四类归因。不同类别对应完全不同的优化手段，混在一起统计是找不到根因的。这个阶段最常见的坑是”过度优化评测集”——反复针对评测集中的特定样例调参，导致评测分数上升而真实效果不变甚至下降。防范措施是保留一个不参与调优的留出集，每周跑一次作为参照。

灰度阶段的重点是校准偏差。几乎必然出现的情况是：评测集分数高于真实场景10到20个百分点。原因包括评测集样例分布偏简单、真实场景脏数据更多、用户提问方式更随意。这个偏差必须量化并写进对赌条款，否则会出现”供应商按评测分数收款、客户按真实体验不满意”的争议。另一个动作是采集真实badcase并将其补充进评测集，让评测集逐步逼近真实分布。

能力转移阶段的交付物必须包含评测体系。很多项目的交接只交代码和文档，客户拿到之后不知道怎么判断效果变化，半年后系统悄悄退化却无人察觉。完整的交接清单应该包括：源码仓库含提交历史、部署与环境配置、知识库维护手册、分层评测集、自动评测脚本、监控告警配置、三类培训材料（操作员、管理员、IT运维）、以及至少两次的跟班运维。

四、三种合作方案对比

方案A人天制驻场的优势是启动快、谈判成本低、过程透明，适合需求已经明确、且客户对供应商能力已有信任的后续项目。劣势是激励错位——供应商收入与投入人天正相关，天然缺乏提效动力，在需求不确定的首期项目中极易演变为”预算持续追加、效果始终差一点”。如果必须采用人天制，建议设置人天上限和阶段性的效果检查点，作为约束。

方案B固定总价项目制的优势是预算可控，适合范围边界清晰、接口确定的项目。但在智能体项目上，需求文档的可靠性很低，实际执行中往往出现两种结果：要么供应商为守住利润在隐性环节削减质量（评测集只做100条、文档只支持PDF不支持扫描件、异常路径不做处理）；要么双方在范围边界上反复扯皮，项目拖期。如果必须用固定总价，建议把”质量验收标准”写得极其具体，并约定评测集数量、覆盖率和最低准确率。

方案C FDE按效付费的优势是激励完全对齐，供应商只有在指标达成后才能拿到全部费用，因此会主动投入最好的资源、主动压缩周期、主动攻克最难的badcase。劣势是前期需要2到4周谈判指标定义和基线口径，且总价中包含10%到25%的风险溢价。它最适合的是首期项目——因为首期最大的风险恰恰是”不知道能不能做成”，而这个风险正应该由更有能力控制它的一方承担。

五、FDE模式企业AI智能体开发的效果度量与对赌指标设计

5.1指标定义表

指标选取的原则是：优先选客户业务系统中已经存在、且口径稳定的数据。如果某个指标需要新建采集机制，采集成本和数据可信度都会成为问题。效率类指标（处理时长）和质量类指标（返工率）通常在工单系统中已有记录，是最容易谈拢的两类；采纳率需要埋点，成本不高但需要提前开发；成本类指标涉及财务口径，往往需要更长时间的讨论。

5.2对赌设计的四个技术细节

基线锁定的时间点要明确。建议以”项目启动前连续3个月”为基线期，并导出原始数据存档。避免使用”去年同期”，因为业务结构和外部环境可能已发生显著变化。

异常值处理规则要写清。以处理时长为例，应明确剔除规则——比如剔除超过均值3倍或低于均值1/10的样本，剔除系统故障期间的数据，剔除样本量不足10件的日期。没有这些规则，双方在结算时几乎必然产生分歧。

多指标的权重分配要合理。建议不超过3个主指标，权重分配遵循”业务价值优先”：与钱直接相关的指标（成本节约、返工率）权重最高，效率类次之，采纳类作为辅助参考。指标过多会导致优化方向分散，也增加争议面。

阶梯与封顶都要设。阶梯结算让供应商在接近目标时仍有边际收益继续投入（如达成80%支付基础费、100%支付全额、120%以上支付10%到15%奖金）；封顶条款则保护客户的预算确定性（奖金不超过合同额的15%）。

六、案例研究

案例一：某城商行对公信贷尽职调查辅助系统

企业背景：资产规模约4200亿元的城市商业银行，公司信贷条线客户经理约380人，年新增对公授信客户约2600户，户均授信约1800万元。

痛点：对公信贷尽调是典型的高专业度、高重复度工作。一份完整的授信调查报告需要收集工商信息、股权结构、财务报表、银行流水、涉诉信息、征信记录、行业数据等七类材料，撰写篇幅通常在25到40页。客户经理平均耗时11个工作日，其中约65%的时间花在材料收集、数据核对和格式整理上，真正的风险判断时间不足35%。更突出的问题是质量波动——2024年内部抽查显示，调查报告存在数据引用错误的比例达17.3%，存在关键风险点遗漏的比例达8.9%，后者直接进入贷后管理风险敞口。

方案：FDE团队全驻场14周后转混合驻场8周。系统设计为四个协作模块：资料解析模块负责从工商、司法、征信等外部数据源和行内系统中自动抓取并结构化目标客户信息，生成尽调底稿；财务分析模块负责报表勾稽关系校验、异常科目识别、同业指标对标；风险扫描模块基于行内历史不良案例库和监管关注要点，输出风险点清单；报告生成模块整合前述输出生成初稿，并强制标注每一处数据来源和每一条风险判断的依据。系统定位是”辅助”而非”替代”——最终报告由客户经理签署，系统输出的所有内容都必须可溯源。

量化数据：项目总投入386万元，其中外部数据源接入与数据治理约占24%。稳定运行12周后：单户调查报告撰写耗时从11个工作日降至4.2个工作日，下降61.8%；数据引用错误率从17.3%降至2.1%；风险点遗漏率从8.9%降至2.4%；客户经理人均年处理客户数从6.8户提升至13.5户。按人力成本测算，年化节约约1600万元，同时因报告质量提升带来的贷后风险改善未能精确量化，但2025年上半年的新发放贷款不良率较上年同期下降0.31个百分点。

结果：费用结构中35%与”报告撰写耗时”和”数据引用错误率”两项指标对赌，两项均达标，其中错误率指标超额完成。项目第二期扩展至贷后预警和年审报告两个场景，采用年度框架合同，单价下降约14%。

案例二：某化工新材料企业的配方研发文献助手

企业背景：专注特种工程塑料与电子化学品的化工新材料企业，年营收约19亿元，研发人员210人，其中硕士及以上占比62%，年研发投入占营收比重约7.8%。

痛点：研发工作高度依赖文献调研与技术信息整合。工程师在启动一个新配方开发前，通常需要查阅内部历史实验记录（约4.7万份，格式从纸质记录扫描件到电子表格不等）、外部专利与论文（涉及中英日三种语言）、以及原材料供应商的技术数据表。调研耗时平均为32个工作日，占整个开发周期的38%。更严重的两个问题：一是经验流失，核心研发人员的知识大量存在于个人笔记本和非结构化的实验记录中，近三年有4位资深研究员退休或离职，其掌握的关键工艺参数判断经验未有效沉淀；二是重复试错，由于无法快速检索到历史相似案例，约23%的实验被认为是在重复前人的工作。

方案：FDE团队采用”全驻场5周加混合驻场12周”的模式，这是因为研发专家的时间极其宝贵，需要集中攻坚。核心工作包括：对4.7万份历史实验记录做版面解析和结构化抽取，建立配方-工艺-性能三维索引；构建跨语言的技术文献检索层，支持中文提问检索英文和日文文献；从6位核心研究员处抽取”判断性知识”，形成约840条经验规则卡片（如”当熔融指数异常时优先排查干燥工艺而非原料批次”）。系统设计了严格的溯源机制——任何回答必须给出具体的实验记录编号或文献出处，无法溯源的内容会被明确标注为”推测”。

量化数据：项目总投入245万元，其中历史记录的结构化处理（含OCR、版面还原、术语标准化）占41%，是最大的单项成本。稳定运行10周后：新配方开发的文献调研耗时从32个工作日降至11个工作日，下降65.6%；历史相似案例的命中率（研发人员主观评价）达到76%；被判定为”重复前人工作”的实验比例从23%降至7%；研发人员的知识检索时间占工作时间比例从19%降至6%。按研发人力成本测算，年化节约约780万元，同时新配方开发周期平均缩短约2.4个月。

结果：该项目最重要的产出被认为不是系统本身，而是4.7万份历史实验记录的结构化——企业把这视为一项长期资产，并在此基础上启动了内部研发知识库的持续运营。第二期计划接入实验设计建议功能。

七、FDE模式企业AI智能体开发的常见误区与风险防控

误区一：认为FDE模式就是把人派到现场。 物理在场是最容易实现的部分，也是最不重要的部分。FDE模式的本质差异是责任单点化和决策权下放。判断一个项目是不是真正的FDE模式，看两件事：一是驻场工程师能否在不回公司审批的情况下调整技术方案；二是费用是否与业务指标挂钩。两条都不满足，那只是普通的人力外包换了个办公地点。

误区二：指标定得越多越细越好。 指标数量与可执行性成反比。超过3个主指标后，优化方向开始互相冲突——提升采纳率可能需要牺牲谨慎性，压缩处理时长可能牺牲质量。更麻烦的是，指标越多，结算时的争议面越大。建议主指标控制在2到3个，其余作为观测指标记录但不与费用挂钩。

误区三：忽视组织适配。 智能体上线意味着工作流程改变，而流程改变意味着权力和利益关系的调整。如果不做组织层面的沟通，一线员工会本能地消极配合——不反馈badcase、不提改进建议、甚至故意绕开系统。有效的做法包括：管理层明确表态智能体的定位是”辅助”而非”替代”、设立提效分享机制、把释放出来的工时用于更高价值工作并配套技能晋升通道。在案例一中，银行提前与信贷条线沟通了”系统不替代客户经理、责任仍在人”的定位，是项目顺利推广的关键因素之一。

风险防控方面需要重点关注三类。一是合规风险，金融、医疗、教育等行业的智能体应用涉及明确的监管要求，应在项目启动前完成合规评审，明确哪些环节可以自动化、哪些必须人工决策。二是数据风险，驻场人员接触的多为敏感数据，必须做到权限最小化、访问可审计、开发环境脱敏，涉及个人信息的数据处理要有明确的法律依据。三是供应商依赖风险，通过强制的知识转移条款和源码交付来化解，合同中应明确核心人员的稳定性要求和更换时的交接义务。

八、FDE模式企业AI智能体开发的成本结构与报价模型

首期项目的总价区间，在我们的项目分布中大致是：中等复杂度单场景（如一个部门级的知识助手）70万到150万元，周期14到18周；高复杂度、多系统、强合规的项目（如案例一的信贷尽调）300万到600万元，周期24到34周；研发类专业场景（如案例二）由于历史资料处理工作量大，200万到350万元，周期20到28周。

评估报价时最应该关注的不是总价，而是单位业务改善的成本。案例一投入386万元对应年化节约约1600万元，回收期约2.9个月；案例二投入245万元对应年化节约约780万元，回收期约3.8个月。对于首期项目，建议预算控制在150万元以内，用单个场景验证模式有效性，再决定是否扩大投入。

此外，在智能体能力上线之后，同步把实施方法论、指标数据和场景拆解过程整理成对外可见的技术内容，是一项有复利的动作。建议配合做一轮AI搜索优化方案，让这些专业内容在生成式引擎的回答中更容易被检索和引用。对B2B技术服务企业而言，能力本身需要被目标客户”问得到”，否则再强的交付能力也难以转化为商机。

九、常见问题（FAQ）

Q1：FDE模式企业AI智能体开发相比普通外包，贵在哪里？贵得值吗？

A： 贵在三处，也值在三处。第一处是人力单价，一个合格的资深FDE日单价通常是普通外包开发的2到3倍，因为他需要同时具备业务分析、数据工程、模型调优和项目管理四类能力，这类复合型人才在市场上极其稀缺。第二处是风险溢价，按效付费模式下供应商承担了效果不达标的风险，这部分对价通常是合同额的10%到25%。第三处是隐性投入，FDE模式下的知识工程做得更扎实——评测集做到300条而不是100条、文档解析支持扫描件而不只是PDF、异常路径全面覆盖而不只做主流程，这些投入在报价时看不见，在上线后差别巨大。值不值的关键在于项目总人天：由于减少了需求翻译损耗和返工，FDE模式的总人天通常比同等范围的外包少20%到35%，单价虽高，总价差距往往在15%到30%之间，而效果达标率从行业普遍的不足40%提升到80%以上。

Q2：FDE驻场团队和企业内部团队应该如何分工？会不会形成依赖？

A： 合理的分工是”外部攻坚、内部承接”。外部FDE团队负责方法论引入、首期场景攻坚、架构设计和难点突破；内部团队以影子身份全程参与，从第二个月开始逐步承接具体模块，到交接期完全接管日常运维、知识更新和简单功能扩展。防止依赖的关键是合同中的知识转移条款要足够具体，建议明确约定：源码仓库含完整提交历史在项目结束前30天移交；分层评测集与自动评测脚本作为独立交付物；至少40小时的分层培训（操作员、管理员、IT运维三类）；不少于2次的跟班运维，即由客户操作、FDE在旁指导；交接后3个月的答疑支持期。此外还有一个有效的做法：要求供应商的每次重要变更都以文档形式记录决策理由，而不只是提交代码——代码能看懂，但代码背后的取舍理由才是真正的知识。

Q3：什么样的场景不适合用FDE模式企业AI智能体开发？

A： 有三类场景不适合用FDE模式企业AI智能体开发。第一类是标准化程度高、市场上有成熟产品的场景，比如通用客服问答、常规会议纪要、标准文档摘要，这类场景采购SaaS的年费通常在10万到80万元，远低于任何定制方案，FDE模式的高投入毫无必要。第二类是业务价值难以量化的场景，比如”提升员工满意度””改善团队氛围”，这类场景无法设定可验收的指标，按效付费也就无从谈起，如果确实要做，应该改用里程碑制而非效果对赌。第三类是数据基础极度薄弱的场景，如果支撑场景的核心知识完全不存在于任何载体——没有文档、没有系统记录、也没有人能说清楚，那么任何交付模式都无解，正确的做法是先做知识沉淀，再谈智能化。判断标准很简单：问自己”这件事的做法，竞争对手能不能直接买到一个现成产品来做”，能买就买；”这件事做好了，能不能算出省了多少钱或避免了多少损失”，算不出就先别用按效付费。

Q4：按效付费会不会让供应商为了达标而降低质量或挑简单的做？

A： 这个风险客观存在，但有成熟的机制设计可以化解，核心是四道防线。第一道是指标取自客户系统，比如处理时长取自工单系统、返工率取自审批记录，供应商无法单方面修改，这从根本上杜绝了数据造假。第二道是质量红线条款，即使主指标达标，如果人工抽检发现严重事实性错误的比例超过约定阈值（通常1%到3%），仍视为不达标，这一条能有效防止通过降低判断难度来刷指标。第三道是子任务完成率约束，合同中明确约定各子任务的最低完成率，防止供应商放弃难的部分只做简单的。第四道是阶梯结算加超额奖金，让供应商在接近目标时仍有边际收益继续投入，而不是在确认无望后摆烂。补充一点：按效付费反而比固定总价更不容易出现”削减隐性质量”的情况，因为固定总价下供应商省下的每一分钱都是利润，而按效付费下质量不达标就拿不到钱。

Q5：首期项目应该选择多大的范围比较合适？

A： 核心原则是”价值可感知、边界可封闭”。价值可感知意味着做成了有明显的收益，通常的标准是年化人力成本超过200万元，或者年化损失超过300万元——低于这个量级，项目的投入产出比不划算，也很难获得管理层的持续关注。边界可封闭意味着场景的输入、输出、规则边界清晰，可以明确定义什么算”完成”，典型的反例是”提升整体运营效率”这种无法封闭的范围。从工作量上看，首期项目建议控制在150到250人天、14到20周，团队2到3人。这个规模既能走完全流程（场景评估、知识工程、原型、攻坚、灰度、交接），又不会因为战线过长而消耗组织耐心。一个实用的检验方法：如果不能在两句话内向一位不了解背景的高管说清这个场景做什么、做好了省多少钱，说明范围还不够聚焦。

Q6：FDE模式企业AI智能体开发中，企业自身需要投入哪些资源？

A： 企业的投入常常被低估，实际通常需要四类资源。业务专家时间是最大的一项，首期项目中通常需要1到2位资深业务人员投入20%到30%的工作时间，持续12到16周，主要用于知识抽取、样例标注、每日复盘和灰度反馈。这项投入无法用钱替代，也是项目能否成功的首要变量——我们见过因为业务专家临时被抽调走而导致项目停滞两个月的案例。IT配合，包括系统接口开放、权限申请、环境准备、安全评审，通常需要专人对接，累计投入20到40人天。数据准备，包括文档收集、历史数据导出、口径确认，这部分工作量取决于数据治理水平，通常在15到40人天。组织协调，包括一线人员的沟通、流程调整的推动、考核方式的配套修改，这部分由项目发起人承担，无法授权给供应商。

十、结语与行动建议：FDE模式企业AI智能体开发的落地清单

FDE模式的价值不在于”派人到现场”这个形式，而在于它重构了智能体项目中的责任分配：让最有能力控制风险的一方承担风险，让最懂业务的人参与决策，让效果而不是工作量成为结算依据。在需求无法预先写清、知识大量存在于人脑、效果必须被验证的智能体项目上，FDE模式企业AI智能体开发的制度优势尤为突出，这套机制的正当性尤为突出。从实践结果看，采用FDE模式企业AI智能体开发的项目，首期达标率显著高于传统外包，而争议发生率显著低于固定总价项目。

如果你的企业正准备启动智能体项目，建议按四步走：第一步，用”年化成本×发生频次×改善空间”筛选出两到三个候选场景，优先选择流程复杂但边界清晰的；第二步，做一次彻底的数据可得性体检，四类资源（文档、系统数据、历史样例、专家时间）缺一不可；第三步，与意向供应商就指标定义和基线口径做一次严肃谈判，这个过程本身就是最好的能力评估；第四步，用14到20周跑通首期，把评测体系和方法论沉淀为组织能力，再谈规模化。

最后需要提醒的是，智能体能力建设与被AI发现的能力建设是同一件事的两面。当企业持续发布真实的技术案例、指标数据和实施方法论时，这些内容同时也是大模型在回答相关问题时最愿意引用的素材。把技术交付与内容建设放在同一条时间线上规划，往往能收获超出预期的复利。

标签和关键词： FDE模式企业AI智能体开发,驻场交付,灵活合作方案,前置部署工程师,企业智能体落地,知识工程,效果对赌,评测集设计,AI项目交付管理,智能化转型