昨天我host了一场space：AI Agent 在企业内如何落地：FDE 的真实工作 邀请了三位嘉宾：泊舟 @bozhou_ai , 阿黄 @UVWka3h 和 思路 @silux001 一起聊了一个小时 准备这场Space时，我最想搞清楚两个问题：企业Agent项目现在到底在交付什么；FDE能不能从一种高度依赖人力的项目服务，做成可持续、可规模化的商业模式。 三位嘉宾刚好代表了三种不同视角。 泊舟接触和访谈过不少国内FDE从业者，也在研究独立FDE团队怎么赚钱；阿黄在大厂服务KA和行业头部客户，做Skill、Agent以及配套云服务；思路则和前CTO搭档，以小型创业团队的方式，同时推进制造、建筑和金融行业的企业Agent项目。 聊完以后，我最大的感受是：企业Agent项目真正困难的部分，通常已经超出了模型和Agent Framework本身。 客户有没有完成基础数字化、业务流程能不能描述清楚、数据和权限能不能拿到、老板的预期是否正常、项目交付完以后怎么持续收费，这些问题最终直接决定一个Agent项目能否落地成功。 一、同样叫“Agent落地”，背后可能是三种完全不同的生意 泊舟分享了一个三人FDE小团队的案例。 他们服务的是一家十几到二十人、没有技术团队的小公司，主要交付Skill定制和企业知识库，帮助客户批量处理文本工作，例如生成脚本。 项目周期大概半个月到一个月，一单成交金额通常只有1万到2万元。 这个数字在扣除税费以及三个人分配后，每个人实际到手收入其实就不太乐观了。 这是一个很典型的陷阱：路径跑通了，但是不赚钱。 阿黄所在的大厂走的是另一种模式。 他们给KA客户定制Skill和Agent，同时提供Agent运行所需的云环境、服务器、数据库、模型调用和部署服务。收入来源里既有人力服务费，也有持续产生的云资源和模型调用费用。 他们做过餐饮点单Agent，把商品、用户等数据接入内部通用Agent中台，再针对点单场景定制Skill；也做研发和运维场景，把定时巡检等重复、流程固定的任务封装成Agent能力。 大厂在这里最大的优势，是能把Agent项目放进原有的云业务收入结构里。Agent软件服务是入口，后面的计算、存储、数据库、模型和技术服务都可以持续收费。 思路的团队则代表了创业型FDE的状态。 他们正在并行推进三个项目。 第一个是传统制造业工厂，产品形态接近AI-native SaaS。用户不再操作复杂的传统SaaS界面，而是直接向Agent表达意图，由Agent完成数据检索、分析，以及设备和订单的生产排程。工作量很大，但技术上总体可行。 第二个是建筑公司，希望用AI把CAD图纸转换成工程量清单。需求非常明确，价值也很直接，但技术难度极高。图纸里包含大量几何关系，不同设计师的制图标准和习惯又不统一，当前多模态模型很难稳定完成几何理解与业务语义映射，所以项目暂时搁置。 第三个是国内某头部券商营业部。他们把固定workflow和pipeline封装为MCP Service，再通过飞书交付Agent和Skill，同时帮助客户整理知识、文档和数据体系。 这个项目的业务流程相对容易实现，真正的阻力来自数据安全、隐私、权限和内部审批。 三个案例放在一起看，会发现“企业Agent落地”只是一个非常宽泛的标签。 独立小团队做的是一次性项目交付；云厂商做的是Agent带动云资源和模型收入；创业团队则在通过项目获得行业know-how，再尝试把重复需求产品化。 项目都叫FDE，收入结构、技术风险和交付逻辑却完全不同。 二、所谓“低垂的果实”，本质上是一套客户筛选机制 我在Space里问了一个问题：哪个垂直行业既能给客户创造足够大的价值，又能让FDE以相对低的成本完成交付？ 几位嘉宾最后形成的共识是，行业标签没有想象中那么重要。真正应该筛选的是客户状态。 一个适合优先做Agent的客户，通常已经具备几个条件： 业务里存在明确、重复的workflow或pipeline；已经有知识库、业务系统和协作工具；数据可以访问，权限能够协调；业务效率可以量化；老板对当前技术能力有相对现实的预期。 阿黄所在的大厂会优先服务原本就在云上的客户，原因很直接：这些企业通常已经完成了一定程度的数字化，数据、服务器和系统都在那里，交付边界更清晰。 思路提到，电商、外贸、互联网等高度数字化的行业通常更容易找到杠杆点。大量信息已经在线，员工也习惯使用飞书等协作工具，FDE不需要从最基础的信息系统开始补课。 很多传统企业的问题还停留在数字化阶段：没有可用的数据体系，文档和流程一片混乱，大量业务事实存在于几个老员工的脑子里。 这时候直接上Agent，FDE很快就会发现，自己接下来的工作包含基础设施建设、数据整理、流程重构和员工教育。Agent项目只是把这些企业的历史欠账一次性全暴露了出来。 所以一个非常重要的判断是： 先选择客户，再选择技术。 最适合优先落地的客户，往往已经有数字化基础，有明确且重复的流程，业务价值可以衡量，同时愿意开放数据和业务上下文。 老板的认知也非常关键。 泊舟提到，有些老板看完几篇文章或几个演示视频，就希望Agent自动理解需求、拆分任务、开发、测试并上线。 这种预期如果在签约前没有被纠正，后面基本一定会失控。 为了拿单而过度承诺，只是把销售阶段的问题推迟到交付阶段。到了验收的时候，所有模糊表达都会变成甲方眼里的承诺。最终验收的时候都是风险。 三、FDE交付链条里，产品、架构和工程缺一不可 关于“哪个角色创造的价值最大”，三位嘉宾的答案并不一致。 思路更看重产品经理和业务理解。 FDE进入一个陌生行业后，首先要快速理解真实业务。企业内部的信息经常不完整，不同部门之间也可能存在阻力。业务事实一旦判断错误，后面的Agent工程做得再复杂，也无法解决真实问题。 很多传统企业真正需要的功能并没有那么复杂。工程师可能拿着一套非常强的Agent架构，最后解决的只是一个流程清晰、规则明确的小问题。 思路的形容很准确：拿着降龙十八掌，去解决一个非常简单的问题。 阿黄则认为，实际交付很难依靠一个角色完成。大厂实践中的最小FDE单元，更接近一个“铁三角”： 商务负责客户关系、识别决策者、协调不同部门和梳理需求；架构师连接业务与技术，把问题转化成可以实现的系统方案；技术服务和交付人员负责真正的开发、部署和上线。 Agent时代，产品思维会逐渐变成这三种角色的共同能力。 泊舟从技术出发，更看重架构和工程确定性。 FDE最终按结果交付，而Agent天然带有不确定性。工程工作的价值，就是在这种不确定性中建立足够的确定性：提高任务完成率和准确率，控制Token消耗，降低调用成本，通过工具、架构和评估体系减少失败。 一个Agent能够比同类方案更可靠、完成率更高、Token成本更低，才真正形成了可以复制的竞争力。 我更愿意把三个人的观点看成一条完整的价值链： 业务和产品决定做什么，架构决定能不能做、怎么做，工程交付决定最终能不能稳定产生结果。 在Space里，我也进一步把完整的Agent交付体系拆成了三层。 前台是FDE，负责商务、调研、方案、交付、培训和维护；中台负责Agent开发、定时任务、API调度、Dashboard、部署和可观测性；后台则提供云基础设施、Sandbox、Memory、Context管理、稳定性和扩容能力。 前台负责拿到真实上下文，中台把一次性交付沉淀成可复用能力，后台负责保障整体Agent系统工程的稳定性。 四、FDE自己必须先成为高度AI化的人 思路在讨论里有一个很好的比喻： 人是Agent在物理世界里的触角。 FDE需要进入客户现场，访谈业务人员，观察真实流程，获取那些没有被写进文档的上下文。 与此同时，Agent可以负责生成调研框架、设计访谈问题、分析已有资料、梳理业务流程，再根据收集到的事实生成PRD、实施计划和解决方案。 人继续回到现场验证，Agent继续加工新的上下文。 这应该成为FDE自己的基础工作方式。 如果一个做Agent交付的人，行业调研、访谈设计、需求梳理、方案生成、开发测试、评估和项目复盘仍然主要依靠手工完成，他的交付成本很难真正降下来。 FDE卖的是企业效率，但首先要把自己的效率提高。 五、一次性交付很难形成一门好生意 三人团队用半个月到一个月交付一单，收入只有1万到2万元，这种模式很难覆盖后续培训和维护成本。 单纯提高客单价可以缓解问题，但很难从根本上改变项目制收入的线性增长。 更合理的收入结构应该包含云资源、模型和Token使用、部署运维、培训维护，以及持续版本升级。 思路和泊舟都提到了Token收入。FDE可以运营模型中转站，也可以和模型服务商、中转站进行分成。客户使用得越多，服务方获得的持续收入越高，也就更有动力继续培训、优化和维护。 阿黄所在的大厂，本身已经在使用类似的结构，只是收入不局限于Token，还包括服务器、数据库、模型、部署和整体云资源。 这种模式的重要价值，在于让服务方和客户的利益逐渐一致。 客户真正使用Agent，服务方才能获得持续收入；服务方持续优化Agent，客户才能获得更高的业务价值。 当然，Token收入本身也解决不了全部问题。真正决定FDE能否规模化的，还是能不能把项目里的重复部分沉淀下来。 每完成一次客户交付，都应该尝试提炼其中重复出现的Skill、Connector、Workflow、评估集和部署能力，再把它们沉淀进Agent中台或Harness。 下一次遇到类似客户时，团队交付的是已经验证过的组件，而不是重新从零搭建一套系统。 单纯扩充FDE人数，只会让收入和管理成本一起线性增长。把现场经验变成中台能力，才有机会持续降低边际交付成本。 六、ROI、获客和项目失败，最后都指向同一个问题：信任 有听众问，传统企业老板连AI能够替代什么都不知道，也没有明确预算，应该怎么沟通ROI。 阿黄的做法是先进行AI转型教育。 先展示大厂内部如何使用AI，邀请HR、运营等角色分享真实经验，再结合其他企业案例，把岗位拆成一个个具体任务，计算每项任务能够节省多少时间、人力成本，或者创造多少新增收益。 一上来就和客户讨论一个抽象的Agent产品，通常没有太大意义。ROI需要落到任务层面，而不是停留在“企业要不要拥抱AI”这种口号上。 FDE怎么获客，答案也很现实。 大厂可以通过面向CEO和关键决策人的活动、分享会和行业教育建立入口；独立团队可以持续发布真实案例，教育不同行业的人如何使用Agent、管理Context和设计工作流。 但在早期阶段，最容易转化的依然是已有关系、过去合作过的客户，以及朋友转介绍。 企业Agent项目需要接触大量内部数据、业务流程和组织信息，客户购买的不只是技术能力，也包括对团队的信任。 还有听众分享了一个Voice Agent项目。因为响应速度太慢，底层调用链和组织结构又过于臃肿，最终丢掉了订单。 这类项目失败后，首先应该判断问题属于哪一类。 如果当前技术和基础设施根本无法满足要求，也找不到现实可行的优化路径，就应该承认边界，停止继续消耗资源，或者重构整个方案。 如果问题来自业务理解不足，就继续获取上下文，重新与客户对齐需求，把模糊争议转化成任务完成率、准确率、延迟等明确KPI，再用一个可验证的新版本重新建立信任。 项目失败并不可怕。真正危险的是，团队既说不清失败来自哪里，也无法给出可以验证的改进路径。 最后 聊完这场Space，我对FDE的判断更明确了。 FDE的本质是结果交付。客户不关心模型Benchmark，也未必理解底层架构。客户最终关心的是，Agent能不能完成任务、节省多少时间、降低多少成本，以及结果是否稳定。 最好的项目起点，通常是客户已经存在的workflow和pipeline。先从一个明确的Skill切入，把边界和指标做清楚，再逐步扩大Agent能够承担的任务。 FDE更像一种靠近现场的产品机制。 先让人进入企业，拿到真实上下文，完成第一个可验证的结果；再把重复出现的需求抽象成中台产品能力，降低下一次交付的边际成本。 只完成前半段，本质上还是外包卖劳动力的生意。 把后半段做出来，才有机会成为一家公司。 企业Agent落地最终会同时碰到技术、组织和商业三套系统。 模型能力在绝大部分场景下已经不是瓶颈，客户的数字化基础和权限决定起跑线，产品、架构与工程决定能否完成交付，收入结构则决定了商业模式的上限。 这是我主持完这场Space以后，最想留下的结论。