模型能写代码，Agent 能调工具，搭一个带对话框的应用也越来越容易了。
但企业 AI 项目里，仍然需要有人去问业务、接系统、处理数据、盯上线。模型进步这么快，为什么这部分工作没有跟着消失？
看 Anthropic 的 FDE 招聘就能发现，它要求工程师进入客户环境，建设生产级应用，并把反复出现的部署方法反馈给产品团队。岗位说明
这件事很值得做开发的人想一想：代码越来越便宜，客户为什么还需要买交付？
一个能跑的功能，离能用的系统还有多远
假设客户提了一个需求：“帮我早点发现快流失的客户。”
用 AI 写个页面，查一下最近联系时间，再列出超过 30 天没有跟进的客户，不难。
但准备上线时，问题才开始出现。
有些客户按季度采购，30 天没联系很正常；有些重点客户每周都要跟进。同一次拜访，销售写在聊天里，CRM 还没补录。客户换了负责人，历史承诺没有交接。合同已经到期，但续约仍在谈。
这些情况不弄清，模型再聪明，也可能拿着不完整的记录做出非常流畅的误判。
工程上至少有四件事要落实：
| 要解决的问题 | 应该落到哪里 |
|---|---|
| 什么算“流失风险” | 业务规则、适用范围、例外条件 |
| 哪些记录可信、多久更新 | 数据来源、对象标识、更新时间 |
| 谁能看哪些客户、谁能调整负责人 | 服务端身份与权限 |
| 提醒以后由谁处理、处理到哪一步 | 业务状态、责任人、回写与审计 |
这里的 30 天只是为了说明问题，真正的阈值必须由业务确认。让模型自己补一个“合理规则”，上线之后反而会多出一套没人承认的管理制度。
所以，生成代码只完成了一部分工作。接下来要把客户脑子里的管理要求，变成系统里有定义、能执行、能检验的规则。
FDE，就是对这段距离负责的人
FDE 是 Forward Deployed Engineer，通常译为前置部署工程师。Palantir 是这一模式的代表公司之一。它的官方岗位说明，把工作范围从客户沟通延伸到数据、应用与实际部署。岗位说明
理解这个角色，不必先纠结是不是每天驻场。关键是工程师直接面对业务问题，也有能力把改动落实到系统里。
还是客户流失预警这个需求。
FDE 要和业务一起确认“异常”的含义，查清楚记录散落在哪些系统里，再决定哪些规则用程序实现、哪些判断交给模型，以及哪些动作需要负责人确认。
随后要接入数据、完成开发，用真实角色验证，处理上线后的反馈。如果预警太多，就回头看是规则不对、数据缺失，还是模型判断失准。
这要求工程师既能写代码，也能听懂客户在担心什么。业务说“这个提醒没用”，未必是在要求换一个模型，有时只是销售刚完成的动作没有进入系统。
FDE 的价值，是把技术能力推进到客户真正能使用的那一步。
那它和软件外包有什么区别？
单看“沟通需求、开发、上线”，确实很像。决定差异的是交付之后留下什么。
如果每来一家客户，都复制一份工程，从账户权限到业务流程全部重写，客户一多，团队就会背上越来越多独立版本。下一次修改，依然需要靠熟悉这个项目的人去处理。
这种情况下，换上 FDE 的名字，不会自动改变生意的结构。
真正有积累的交付，需要把两类东西分开。
通用能力进入平台：身份权限、系统连接、流程执行、部署、日志和测试工具。客户特有的业务要求留在业务层：区域保护怎么做、什么情况允许延期、审批由谁负责。
下一家客户进来，工程师从已有能力继续往前做。上一家客户的私有数据和专有规则，也不应被当成通用素材搬过去。
衡量这套模式，可以看几个很实在的问题：第二次做同类场景少做了哪些工作？平台升级是否需要逐个手工改项目？客户提出新规则之后，能不能定位受影响的功能并验证？
优秀的软件外包和实施团队同样会做这些积累。FDE 不是一道身份分界线，平台复用和对结果负责才值得研究。
Agent 加进来之后，交付反而多了一层要求
传统按钮通常对应一个比较明确的动作。Agent 接到的任务却可能是：“看看这些客户为什么最近不下单，帮我安排一下跟进。”
它要判断该查什么、怎么解释信息、要不要调用工具。这个过程更灵活，也更依赖上下文。
我们不能只在提示词里写一句“遵守公司规定”。至少要让系统回答：当前是谁在操作，他能读什么、能改什么，这一步执行成功没有，失败后能不能重试。
比如创建跟进任务时，不能因为一次网络超时，就让重试多生成三条任务。读取客户情况时，也不能把销售无权查看的客户记录先交给模型，再要求它“不要泄露”。
权限应在读取和执行处校验，重试要有幂等约束，执行结果要回到业务状态里。模型负责判断的部分，也需要有可以复核的依据。
这些工作不够显眼，但它们决定一个 Agent 能否进入日常工作。
如果都要靠高手现场解决，怎么普及？
这是我做 Tacore 时一直在考虑的问题。
企业需要个性化系统，但很多业务部门没有完整技术团队。如果服务更多企业，就必须按比例增加既懂业务又懂工程的人，交付很难真正普及。
我们的做法，是建设企业 AI OS，把业务数据、知识、规则和执行状态组织起来；同时把实施经验、工程规范以及开发、测试、部署能力沉淀成 AI FDE 工具箱，供 Coding Agent 使用。
业务人员提出目标、提供资料、确认业务规则，Agent 借助工具完成更多工程工作。客户仍然要确认规则和验收结果，但不必先学会数据库、接口开发和部署，才能表达自己的需求。
这里真正要积累的，是一套能反复使用的交付能力。不能把一份很长的提示词当成全部工具箱，也不能用“应用启动了”替代“业务跑通了”。
如果你也在做企业 Agent，可以拿当前项目问自己一句：除了代码，还有哪些关键知识只存在于实施人员的脑子里？
把它们变成明确的规则、工具和验证方法，往往比再增加一个聊天入口，更接近客户愿意持续使用的产品。
本文是「企业 AI：从交付到上下文」系列第一篇。下一篇讨论：哪些 FDE 工作可以被产品化，以及 Coding Agent 需要怎样的工程环境。
