企业 AI 为什么总停在 Demo？FDE 真正交付的不是 Agent，而是价值闭环

企业 AI 为什么总停在 Demo？FDE 真正交付的不是 Agent，而是价值闭环

从每天约 2000 个航班的盈亏核算出发，讨论企业 AI 如何从“会回答”走向“能发现、能决策、能执行、能验证”。

写在前面

最近参加了一场关于企业 AI 落地的架构师交流。分享中既有航空、汽车制造等大型企业项目，也有基于多 Agent（智能体）、Skill（技能）和 MCP（Model Context Protocol，模型上下文协议）构建数字员工的实践。

说明：本文受易自成老师在该场交流中的分享启发。航空成本与数字员工案例来自现场分享；“三流一环”、30 天落地路径与四层评估模型，是我在此基础上的二次分析和架构化总结。

两个小时的内容很多，但我整理之后发现，真正值得讨论的并不是某个工具有多少功能，也不是搭建了几个 Agent，而是一个更根本的问题：

企业究竟如何证明，AI 不只是生成了一份报告，而是真的改变了业务结果？

这也是 FDE（Forward Deployed Engineer，通常译作前线部署工程师或前沿部署工程师）与普通 AI 应用开发最明显的区别。FDE 不应只对“功能是否上线”负责，更要对业务结果是否发生可验证的变化负责。

本文同时结合 Palantir、Anthropic、MCP、A2A 与 WorkBuddy 的公开资料校正相关术语。案例数字沿用分享口径，重点用于说明方法，不构成对具体企业经营数据的独立审计。

读完本文，你将获得四个可复用的结果：

• 一套将企业 AI 与业务价值连接起来的“三流一环”模型；
• 一组设计数字员工职责、上下文与工具权限的原则；
• 一条从只读分析走向受控执行的 30 天参考路径；
• 一套同时覆盖任务、业务、治理与经济性的评估框架。

一、一个看似简单的问题：今天这趟航班到底赚没赚钱？

在某大型航空公司的航线效益项目中，管理者想解决的问题非常直接：

南京飞北京的某个航班，今天到底是赚了，还是亏了？

表面上，这似乎只是做一张利润报表。

但当企业每天运行约 2000 个航班时，这个问题会迅速演变成一个复杂的系统工程。因为一趟航班的成本并不只有燃油和机组工资，还可能涉及：

• 飞机购置、融资租赁或经营租赁成本；
• 机身、发动机维修与航材成本；
• 机场服务、航路、起降与地面保障费用；
• 飞行员、乘务员及培训成本；
• 客票销售、收入确认和渠道服务成本；
• 总部管理、信息系统和公共资源分摊；
• 不同国家和机场的油价、汇率及其他动态因素。

分享中提到，相关成本项超过千项，计算规则甚至达到数千条。过去依赖 Excel（电子表格）处理时，不仅慢、容易出错，而且中间分摊过程难以追溯。

更重要的是，管理层需要的不只是月底关账后知道“上个月亏了多少”，而是希望在航线安排、运力投放和预算仍可调整时，就看到接近实时的成本与收益。

例如，当企业需要判断一架 A380（Airbus A380，空中客车 A380）更适合飞伦敦还是洛杉矶时，仅凭经验很容易变成“拍脑袋”。只有把飞机小时成本、维修、油耗、航路费用、客票收入等拆到足够细的业务单元，决策才有可计算的依据。

这个案例揭示了企业 AI 落地的第一个真相：

AI 的起点不是模型，而是一个能够被计算、被追溯、被比较的业务世界。

二、别急着造数字员工，先把业务变成“可计算对象”

这个项目借鉴了 ABC（Activity-Based Costing，作业成本法）的思想。

它的基本逻辑并不复杂：

资源：资金、人力、设备、时间、系统
                  ↓ 成本动因
作业：维修、开票、审核、拜访、订单跟踪
                  ↓ 归集与分摊
成本对象：航班、订单、产品、客户、渠道

企业不是因为“存在”而产生成本，而是在执行一个个作业时消耗资源。

开一次两小时的会议，会消耗参会人的工时、会议室、水电和管理成本；处理一张发票，会消耗财务人员时间、系统资源和复核成本；完成一次客户拜访，也会产生人员、交通、差旅和机会成本。

当企业能够为这些作业建立稳定的定义，就可以形成四类基础资产：

1. 作业字典：企业究竟在做哪些事情；
2. 成本动因：成本按次数、工时、飞行小时、订单数还是人数计算；
3. 标准成本：一次作业在正常情况下应消耗多少资源；
4. 业务基线：当前成本、时长、错误率和产出水平是多少。

这四类资产的重要性，甚至高于最初选择哪个模型。

因为没有业务基线，就无法判断 AI 是否真正改善了结果；没有稳定的作业定义，Agent 也不知道自己究竟应该对什么负责。

从架构角度看，这已经非常接近一个轻量级业务本体：对象是什么、对象有哪些属性、对象之间有什么关系、什么行为会改变对象，以及这些变化如何映射到价值。

三、FDE 真正交付的不是 Agent，而是可验证的变化

很多企业 AI 项目的交付物仍然是：

• 一个可以聊天的页面；
• 一个连接知识库的问答助手；
• 一份自动生成的分析报告；
• 一套看起来很完整的多智能体演示。

这些东西可以证明“技术能运行”，却不一定能证明“业务有收益”。

一个面向结果的 FDE 项目，至少要回答五个问题：

例如，对财务审核场景，不能只写“使用 AI 提升效率”，而应明确为：

上线前：
- 月均人工工时：480 小时
- 平均处理周期：3.2 天
- 复核错误率：2.4%
- 单据平均处理成本：18 元

上线后目标：
- 人工工时下降 40%
- 处理周期缩短至 1 天以内
- 错误率下降至 1% 以下
- 单据平均处理成本下降 30%

这里的关键不是数字一定要多漂亮，而是必须存在一条可验证的因果链：

AI 能力投入
    ↓
具体作业方式改变
    ↓
成本、效率或风险指标变化
    ↓
业务价值被确认

换句话说，FDE 的核心交付物不是“Agent 已上线”，而是：

某个明确的业务对象，在可控边界内，因为 AI 的介入产生了可度量的变化。

四、企业 AI 的核心架构：三流一环

将分享中的航空成本、数字员工、多 Agent 与业务执行过程重新组合后，我认为可以归纳为一套“三流一环”架构：

数据流（Data Flow）
        ↓
智能体流（Agent Flow）
        ↓
工作流（Workflow）
        ↓
反馈环（Feedback Loop）
        └──────────────→ 反向优化数据、规则、Skill 与 Agent

1. 数据流：让 AI 看见真实业务

数据流负责回答“发生了什么”。

企业可用的数据通常来自 ERP（Enterprise Resource Planning，企业资源计划）、OA（Office Automation，办公自动化）、CRM（Customer Relationship Management，客户关系管理）、数据库、文件和 Excel。

但只接入业务单据还不够。企业 AI 至少需要区分四类数据：

很多传统 ERP 拥有较完整的主数据和交易数据，却缺少过程与行为数据。例如，销售拜访在线下完成，没有形成可追踪记录；异常处理依赖口头沟通，没有进入系统。

这时即使模型再强，也只能看到结果，无法稳定判断原因。

2. 智能体流：让不同数字员工各负其责

智能体流负责回答“谁来理解、分析和决策”。

分享中的实践采用了“一个主理 Agent + 多个专业 Agent”的组织方式：主理 Agent 负责理解意图、拆解任务、分派工作、交叉验证和汇总；专业 Agent 分别负责成本、预算、盈利、风险或数据分析等具体职能。

这种设计的重点不是 Agent 数量，而是职责边界。

一个可持续运营的数字员工，应当满足三个条件：

• 职责小而清晰：只负责一组高度相关的业务任务；
• 上下文受到控制：只加载完成当前职责所必需的信息；
• 工具权限最小化：只能访问被授权的数据、Skill 和工具。

这可以称为“最小自治单元”。它类似软件架构中的高内聚、低耦合，也类似组织设计中的岗位说明书。

如果一个 Agent 同时负责财务、销售、法务、采购和人力，并挂载数百个工具，它看似无所不能，实际会带来工具选择错误、上下文污染、权限失控、Token 成本上升和评估困难。

更合理的做法是建立一张角色—能力—工具矩阵：

MCP 可以为 Agent 提供访问数据、工具和工作流的标准接口；当不同团队、不同系统或不同厂商的独立 Agent 需要跨网络协作时，才需要进一步考虑 A2A（Agent2Agent，智能体间通信协议）。

协议不是越多越好，关键是边界是否清楚。

3. 工作流：让建议进入真实业务

工作流负责回答“接下来真正做什么”。

企业 AI 最容易停在“发现问题并给出建议”这一步。例如，系统发现一笔长期挂账、一个预算即将超支，或者某个产品持续亏损，然后生成一段分析文字。

但企业真正需要的是：

• 找到对应责任人；
• 生成待办或审批卡片；
• 带上业务单据和判断依据；
• 经人工确认后发起付款、调拨、补录或纠正流程；
• 将处理结果写回 ERP 或 OA；
• 保留完整审计轨迹。

例如，系统判断销售部门预算将在四天内超支，同时发现人力部门存在可调拨余额。真正的闭环不是输出“建议调拨预算”，而是生成一张预算调拨申请，由授权人确认后进入正式工作流，并在执行后重新计算预算预测。

因此，数字员工不是一个更聪明的聊天框，而是企业工作流中的一个受控参与者。

4. 反馈环：让系统越用越可靠，而不是越用越混乱

反馈环负责回答“刚才的判断是否有效”。

假设系统反复推荐某类作业进行 AI 自动化，但实际 ROI（Return on Investment，投资回报率）持续为负。一个没有反馈机制的系统会继续输出同样的建议；一个具备反馈环的系统则应当：

1. 记录推荐、人工处理和最终结果；
2. 对失败案例进行聚类与根因分析；
3. 生成规则或 Skill 的修改候选；
4. 由管理员审核；
5. 更新后重新执行评测；
6. 通过后再进入生产环境。

需要强调的是，“自我进化”不等于允许模型自行修改生产规则。企业场景中的正确做法通常是：

AI 发现模式并提出候选，人类审核并授权，系统完成版本化更新和回归验证。

五、多 Agent 不是默认答案，复杂度必须与价值匹配

多 Agent 很容易成为演示中的亮点，但它会引入额外的任务协调、上下文传递、结果冲突、Token 消耗、延迟和评估成本。

因此，架构选择应从任务性质出发：

在分享中的实践里，WorkBuddy 被作为专家、Skill、MCP 和多 Agent 组合的承载平台。这个选择可以提升原型与交付效率，但真正应当沉淀的资产不应只存在于某个平台的聊天记录中，而应包括：

• 业务对象与作业字典；
• 角色和权限定义；
• 可复用 Skill；
• 数据与工具连接器；
• 工作流契约；
• 评测集、失败样本和验收指标。

这样，底层模型或 Agent 平台升级时，业务能力才不会被完全锁死。

六、AI 落地经常会逼企业“补一堂数字化的课”

企业启动 AI 项目后，经常会发现一个尴尬的问题：不是模型不会分析，而是关键数据从未被记录。

要判断一个客户为什么流失，需要客户接触、销售拜访、报价调整和服务响应记录；要判断订单为什么延期，需要排产、物料、审批、异常处理和责任交接记录；要判断成本为什么超支，需要知道哪个作业、在什么时间、以什么资源完成。

如果这些过程仍在线下发生，AI 就会遭遇“数据断层”。

这意味着企业 AI 项目往往同时承担两项任务：

1. 在已有数据之上构建智能能力；
2. 反向识别信息化与数字化没有覆盖的业务环节。

所以，AI 就绪度不只是“有没有知识库”或“有没有大模型账号”，还应包括：

• 关键业务是否在线；
• 对象与字段是否统一；
• 流程状态是否可追踪；
• 行为是否留痕；
• 指标口径是否一致；
• 权限和责任是否明确。

某种意义上，AI 是企业数字化成熟度的一面放大镜。过去可以被人工经验掩盖的数据问题、流程问题和职责问题，在 Agent 开始执行任务时都会集中暴露。

七、一个可执行的 30 天落地节奏

结合分享中的交付节奏，我将一个小型 FDE 项目整理为四周路径。它不是适用于所有企业的固定工期，但可以作为控制范围、尽快获取证据的参考。

第 1 周：确认问题和基线

• 选择一个高频、可量化、有明确责任人的业务对象；
• 画出从输入到结果的最小业务流程；
• 建立作业字典、数据清单和指标口径；
• 计算当前成本、工时、周期、错误率或损失；
• 明确哪些情况属于 No-Go（暂不适合做）。

本周的交付物不是 Agent，而是一页式问题定义和基线报告。

第 2 周：完成只读型数字员工

• 接入必要的业务数据；
• 建立一个专业 Agent 或一条智能工作流；
• 将领域方法沉淀为 Skill；
• 准备真实历史案例作为评测集；
• 输出诊断、证据和建议，但暂不写入生产系统。

本周目标是证明：系统能否稳定识别问题，而不是只在演示样本上表现良好。

第 3 周：接入受控工作流

• 在沙箱或测试环境中接入 OA、ERP 或消息系统；
• 对高风险动作加入人工确认；
• 设置最小权限、审批条件、幂等和回滚机制；
• 记录输入、推理依据、工具调用、审批和执行结果；
• 对异常、拒绝和超时设计明确的兜底路径。

本周目标是从“会分析”进入“能协助执行”。

第 4 周：验证价值并决定是否扩展

• 与上线前基线比较；
• 分析成功率、人工接管率、错误率、成本和周期；
• 复盘失败样本，修改规则、Skill 或数据；
• 判断继续扩展、限定范围，还是停止项目；
• 将可复用能力沉淀为模板，而不是复制一套新代码。

项目能否继续，不应由演示效果决定，而应由数据决定。

五类应当谨慎启动的场景

如果一个需求同时存在以下问题，就不适合直接进入 Agent 开发：

• 没有明确的使用者和责任人；
• 没有稳定的数据来源；
• 无法建立上线前基线；
• 结果无法客观验收；
• 业务损失低于建设与运营成本。

“暂时不做”也是 FDE 的专业结论之一。

八、FDE 更像一支小型特种团队，而不是一个超级个人

企业 AI 落地同时涉及业务、数据、模型、系统集成、流程、权限和组织协作。要求一个人长期包办全部工作，风险很高。

更现实的做法是一支小团队覆盖五类能力：

1. 业务诊断能力：理解行业、访谈用户、识别真正损失；
2. 快速构建能力：完成数据接入、Agent、RAG（Retrieval-Augmented Generation，检索增强生成）和原型；
3. 方案架构能力：选择工作流、单 Agent 或多 Agent，设计权限、可靠性与评测；
4. 交付运营能力：部署、监控、审计、迭代并处理生产问题；
5. 客户共创能力：推动责任人参与，建立基线、目标和验收共识。

这也是为什么 FDE 不能被简单理解成“会写 Prompt 的实施顾问”或“懂业务的程序员”。它更接近一种工作方式：工程师进入真实业务现场，为结果负责，同时把现场经验沉淀为可复用的产品能力。

九、衡量一个数字员工，至少要看四层指标

数字员工不能只用“回答得像不像专家”来评估。

1. 任务层

• 任务完成率；
• 信息提取准确率；
• 工具调用成功率；
• 异常识别率；
• 人工接管率。

2. 业务层

• 工时、周期和单位成本；
• 错误、损失和风险变化；
• 收入、利润或转化变化；
• 预算预测与实际偏差。

3. 治理层

• 越权调用次数；
• 高风险动作拦截率；
• 决策依据可追溯率；
• 审批、回滚与审计完整性。

4. 经济层

• 单次任务 Token 成本；
• 模型、工具和基础设施成本；
• 人工维护与评测成本；
• 综合 ROI 和回收周期。

只有任务指标、业务指标、治理指标和经济指标同时成立，数字员工才有资格进入企业核心流程。

结语：企业 AI 的分水岭，是能不能完成最后两步

企业 AI 的成熟度可以粗略分为五个阶段：

聊天工具
  → 知识助手
  → 分析助手
  → 数字员工
  → 决策与执行闭环

从聊天工具到分析助手，模型能力非常重要；从分析助手到数字员工，工程和业务设计开始成为决定因素；而从数字员工走向决策与执行闭环，真正困难的是数据、流程、权限、责任和反馈。

回到开头那趟航班。

一个聊天机器人可以解释航空公司有哪些成本；一个分析助手可以读取报表并指出异常；一个数字员工可以持续核算每个航班的收益；但只有当系统能够进一步回答下面的问题时，AI 才真正进入企业运营：

• 为什么亏损？
• 应该调整什么？
• 谁来审批？
• 如何进入现有流程？
• 执行后是否有效？
• 下一次能否做得更好？

所以，FDE 真正交付的从来不只是一个 Agent。

Agent 只是载体，业务对象是骨架，数据是血液，工作流是手脚，反馈与评测才是神经系统。最终被交付的，应当是一个能够持续产生并证明价值的闭环。

最后也想留下一个问题：你所在团队的 AI 项目，目前停在“能回答、能分析、能执行、能验证”的哪一层？真正卡住你们的，是模型、数据、流程，还是责任边界？

参考资料

1. Palantir Blog：A Day in the Life of a Palantir Forward Deployed Software Engineer
2. Palantir Foundry Documentation：AI FDE Overview
3. Anthropic Engineering：Building Effective Agents
4. Anthropic Engineering：How We Built Our Multi-Agent Research System
5. Model Context Protocol Documentation：What Is the Model Context Protocol?
6. Google Developers Blog：Announcing the Agent2Agent Protocol (A2A)
7. 腾讯云：WorkBuddy Enterprise 产品与“专家”相关文档