决策智能热起来之后：FDE 的「综合交付能力」到底指什么

推荐语

决策智能成热点，FDE「综合交付能力」如何定义？本文拆解其在决策智能领域的具体体现，助你理解关键能力构成。 核心内容： 1. 决策智能解决的核心问题（目标与过程） 2. 企业决策职能体系的组成与运行骨架 3. 决策中心平台能力的展开与能力清单解释

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

能力清单提出之后，还需要进一步的解释

下面两篇文章以最近很热门的决策智能领域为例，解释这些综合交付能力具体指什么？

本文主要包含两部分：一是企业决策职能体系的组成与运行骨架；二是尝试对以决策为中心的平台能力展开讨论。

一、决策智能在解决什么

决策智能这类说法，核心并不神秘：组织希望把重要业务决定，从散落在报表、会议纪要和聊天建议里的状态，变成可设计、可比较、可批准、可执行、可复核的过程。

它通常要求几件事同时成立：

决策本身能被显式说清楚——对象是什么、目标是什么、约束是什么；

方案能被编排与执行，而不停在口头建议；

过程可监控，关键步骤可解释、可审计；

执行结果能回来修正下一次判断。

这与「再上一个预测模型」或「再接一个大模型聊天窗口」不是同一个命题。

二、一个可核对的反例：预测或建议为什么不够

我们以一个供应链中常见的补货场景为例：在促销前夜，我们希望检查一些冷链营养品所在的目标仓库是否缺货。业务人员真正要回答的，往往是一串连在一起的问题：

现在要不要补？补多少？向哪个供应商采购？能否需要调拨？预算与仓容是否允许？谁来批准？写入业务系统后是否真的能创建补货单？事后怎样判断这次决定是否正确？

此时，若系统只给出：

未来七天需求中位数约 980 件，区间约 820–1,180 件。

或聊天界面只给出：

建议补货 1,000 件。

这两类输出都有价值，但这不构成一次完整的决策。原因可以逐条核对：

已有输出

仍未回答

需求预测

向哪家供应商下单、数量如何拆分

「建议补 1000」

预算、仓容、合同、安全库存等硬约束是否通过

自然语言建议

谁批准、依据是什么、可否审计

页面上的方案文案

ERP / WMS 是否产生真实回执

因此，综合交付能力在决策智能题域里的第一层含义是：

能把一次业务决定，推进到约束可检查、人可批准、系统可回执的阶段——而不是停在预测报表或聊天建议。

三、上一篇文章中提到的各项能力指什么

下表是对上一篇能力清单的解释。每一行都尽量对应可观察产出，便于理解。

能力

在决策智能项目里「指什么」

可观察产出（例）

编码能力把已选方案做成可运行的路径：决策界面、系统接口、系统写回、测试用例与验收标准

演示路径可走通；业务系统有回执，而不是模型给一个已执行的回复

数据技术熟悉度把烟囱系统对齐到决策对象；区分事实与预测；状态可计算

可用库存、缺口、业务约束数据可核对；口径冲突有取舍分析逻辑并且可解释

大模型深度使用辅助起草决策定义、抽取规则与合同要点、拆任务与编排；关键的审批流程实现人在回路

有草案、有人工确认；事实/预测/建议有标签

行业业务理解定义决策对象、业务目标、业务约束、责任人

场景说明书或决策定义模版，而不是功能点清单

除了上面的能力以外，在决策智能里同样关键的综合能力：

综合能力

含义

可观察产出

编码/数据技术/大模型使用/行业理解完成数据对齐、多智能体系统搭建、业务语义定义等。

多智能体只能在约定对象与业务规则范围内进行跟中操作；越权或幻觉会被拦住。

交付验收

利用通用的平台底座提供可复用的决策能力；现场补齐真数据、约束与写回等能力

几周内产出可审批、可执行的一真实应用，而不是无限的再改一版的阶段性产物

重要原则： 业务理解往往是可复用的门槛（因为业务知识通常是相对静态的）；真正长期消耗精力的，仍是数据对齐、编码与验收标准、以及模型使用能力。

四、这些能力的组成与运行主线

现在我们还需要一张系统由什么组成、一次决策怎样跑完的地图，否则能力会重新变成口号。

企业决策智能体系用两条主线描述同一件事：

组成主线：决策智能由什么构成

七层自上而下可以读成：业务要决定什么 → 应用如何承载责任 → 决策智能内核如何比较行动 → 智能体如何组织任务 → 模型如何提供理解与预测 → 本体与数据如何描述业务世界 → 计算基础如何支撑表示与约束下的选择。权限、审计、合规与人工审批横切各层。

综合能力并不是漂在系统之外的软实力，而是分别压在这些层上的工程动作。

例如：业务理解主要落在场景与决策定义；数据技术主要落在本体与数据及接入；编码主要落在应用、执行与写回；大模型深度使用主要落在草案、编排与可解释，且必须受下层对象与动作的约束。

执行流程：决策智能如何运转起来

九步描述一次决策的运行顺序：触发 → 定义 → 状态理解 → 候选方案 → 后果预测 → 方案评价 → 选择与审批 → 执行与协同 → 反馈与学习。

用它核对很直接：

只有触发和预测，没有定义与约束 → 还是报表；

有方案文案，没有审批与执行回执 → 还是建议；

有执行，没有反馈 → 难以证明这次决定是否有效，也无法改进下一次决策。

上面的两张架构和流程图中的七层结构决定了由什么组成，九步流程图回答了这套结构式如何运行的。综合交付能力，就是 FDE（或承担同等职责的人或团队）能否在现场推动九步跑完，并让七层中的关键缺口被盖住。

多智能体在这里扮演什么角色

决策智能讨论里常出现智能体。上一篇已强调：多智能体不是多个模型自由讨论。下面的任务图，以一个供应链领域的补货场景，把这一点画得更清楚——任务有依赖、结果有契约、工具有权限、失败可转人工。

因此，大模型深度使用这件事儿在决策智能里的可验证含义，至少要包括：

会不会把复杂决策拆成有职责的任务，而不是一轮超长对话；

会不会让输出接受对象、动作与权限约束；

会不会在该人工审批的步骤停住，而不是自己生成一段文字描述就完了。

编码能力与验证，在这里表现为：契约校验、权限控制、失败重试与转人工路径是否真的存在。

六、交付检查

行业讨论以决策为中心的平台时，常见能力维度可以概括为六类（表述按工程理解归纳，便于自检）：

检查维度

问的是什么

与综合能力的关系

决策是否被建模

对象、目标、约束、输入输出是否说清

业务理解 + 模型辅助起草

人机是否可协作

谁决定、谁确认、摩擦是否可控

业务理解 + 现场收敛

能力是否可组合

是否可复用，而非一次性脚本

编码 + 数据接入

决策是否可执行

批准后能否写入业务系统

编码 + 写回

过程是否可监控

状态与结果能否被看见

数据技术 + 编码

是否可治理

日志、权限、依据能否追溯

证据、审批、审计

这六类不是采购口号，而是一个checklist。上一篇文章说的综合交付能力，正对应谁来盖住这些检查项：一个人能力覆盖越全，小队可以越小；缺哪一块，项目就更容易停在 Demo，无法交付。

也可收成四条更短的业务验收语言：

可解释、可审批、可执行、可反馈。

四条都成立，才比较接近决策智能交付；只满足前两条，多半仍是分析或演示。

结语

用补货反例说明：预测与聊天建议不等于交付；

把四项能力翻译成决策场景中的动作与产出；

用七层组成、九步运行过程与多智能体任务图，标明这些能力落在系统的何处，以及交卷时应检查什么。

当写代码的成本越来越低，稀缺的仍是能把一次业务决定收敛成可运行系统的人。