FDE必备：一文让你学会传统行业如何进行 AI 技术性改造

一、背景

很多传统行业老板觉得 AI升级改造就是找个讲师培训个几天就搞定了，结果培训几天后，讲师教了什么案例，他们只知道这些案例而已，该不懂的依旧不懂，为什么？除了因为没有 FDE 入场，更多的是企业内部的 FDE 存在以下的问题

• 认知模糊：Agent、Skill、MCP、CLI、Model 等概念密集出现，工程边界与调用层级缺乏统一界定。

• 存量系统包袱重：运行多年、架构老旧的 OA、PLM、MES 等异构系统缺乏标准化改造路径，缺乏兼顾安全与稳定性的切入点。

这篇文章全面梳理这一技术栈的分层关系、调用链路，以及存量系统落地的可行工程路径。

二、 五大核心概念的关系架构与职责分层

整个体系并非单点工具，而是一套分层协同的控制与执行链条：

概念边界与核心职责

• Model（推理基座）：本质是无状态的算力与概率推理引擎，负责语义解析、逻辑推理与生成。Model 本身无法直接感知或操作企业内部网络与数据库。

• Agent（调度中枢）：目标驱动的自主控制系统，维护会话上下文与执行记忆，通过 ReAct 或规划反思循环完成任务拆解、工具选择与结果整合。

• Skill（流程资产）：领域工程资产与业务 SOP，包含触发条件、操作规约、参数校验及受控工具清单，相当于写进系统的标准化作业指导书。

• MCP（标准互通协议）：模型上下文协议（Model Context Protocol），采用开放 Client/Server 规范，解耦 Agent 调度与外部系统接口，统一入参/出参的格式与元数据定义。

• CLI（执行工具）：命令行执行接口，具备高确定性输入、易于结构化输出的特点，作为 Agent 底层轻量、直接的物理执行管道。

关键工程关系：MCP 与 CLI 的嵌套

MCP 与 CLI 不是非此即彼的竞争关系，在落地场景中，**MCP 往往充当 CLI 的协议外壳，**例如将运维脚本或底层程序封装为 MCP Server：CLI 负责在隔离环境中执行确定性命令并输出结构化 JSON，MCP 则负责将其对外暴露为标准工具 Schema。

三、 一次工具调用的完整接力过程

以员工通过交互界面发出“帮我查询上周请假审批状态并计算剩余年假”为例，各模块在运行时的完整流转如下：

• 目标接收：用户向终端发送自然语言请求；

• 意图拆解：Agent 将对话上下文投喂给 Model，Model 判断任务需要查询考勤数据，但缺少实时业务数据；

• 加载规约：Agent 检索并加载“HR 考勤 Skill”，读取允许调用的工具清单与字段约束；

• 协议调用：Agent 通过 MCP 协议构造 JSON-RPC 消息，向对应 MCP Server 发起工具调用；

• 底层触达：MCP Server 将请求转换为底层老系统的 REST API 调用，并注入身份认证凭据；

• 回传组装：业务系统返回原始数据，经 MCP Server 过滤并结构化封装后回传给 Agent；

• 生成答复：Agent 结合返回数据与原任务目标，让 Model 生成自然的答复文本并呈现给用户。

四、 存量系统的三级改造路径与决策决策

对存量老系统的适配改造没有统一模版，必须依据系统的技术体检结果进行分级推进：

改造路径选择与原则

• 路径一：API 封装（首选方案）适用于系统具备完整或可用 REST/SOAP/RPC 接口的场景。在原系统外部部署轻量 MCP Server 做协议转换。原则是保持封装层无状态，严禁在封装层重写业务逻辑。

• **路径二：CLI 包装（次选方案）**适用于无对外网络接口，但具备本地 SDK、Shell 脚本或命令行工具的系统。先将输出改造为结构化 JSON，再通过 MCP Server 对接执行。

• **路径三：RPA 兜底（过渡方案）**仅针对纯 Web/桌面 UI 且无任何接口的封闭系统，使用无头浏览器或界面模拟操作。该方案维护成本高、界面变动易导致脆断，仅作为短期过渡手段。

企业级安全与鉴权机制

• 凭证透传（On-Behalf-Of）：支持 OAuth 2.0 的系统应透传用户 Token，保持最小权限原则。

• 服务机器人账户 + 审计底账：若底层只支持静态凭证，使用虚拟服务账号代理操作，但 MCP 必须强记录发起人 ID、原始 Prompt 与调用链。

• 人机协同确认（Human-in-the-Loop）：对写入、审批、删除等高危操作设置硬拦截，强制弹出确认交互，严禁 Agent 全自动执行。

五、 MCP 的实现形式与技术选型

选型时需严格区分传输方式与架构拓扑：

1. 传输协议选型

• stdio（标准输入输出）：Host 进程通过子进程拉起 MCP Server，依赖标准管道通信。适用于本地桌面客户端（如 Cursor、本地分析 Agent），具备高安全隔离度。

• Streamable HTTP（官方推荐远程方案）：单个 HTTP 端点支持 POST 请求与 GET 流式监听，原生支持会话持久化与状态恢复。企业集中部署、多系统共享的首选方案，搭配 OAuth 2.0 使用。

• HTTP + SSE（历史弃用方案）：双端点早期设计，存量项目维持，新项目应向 Streamable HTTP 迁移。

• WebSocket（生态扩展方案）：适合全双工通信及浏览器插件桥接场景，但需妥善处理网络负载均衡与长连接保活。

2. 架构拓扑

• 点对点直连（Point-to-Point）：Agent 逐一直连各系统 MCP Server，适合轻量测试场景。

• 统一网关代理（MCP Gateway / Proxy）：在核心 Agent 与业务系统间设立网关，统一负责访问控制、Token 配额、审计追踪与服务发现。

六、 典型落地案例分析

案例 1：某整车制造企业请假系统接入（B/S 架构，路径一）

• 现状：Java Web 系统，具备内部 REST API，原操作需员工在网页多层跳转，月末人工对账繁琐；

• 方案：底层业务代码保持不变，独立构建 Streamable HTTP 协议的 MCP Server 微服务，打通企业 SSO 单点登录；

• 成效：实现自然语言交互请假与额度查询，操作链路大幅压缩，底层数据权限与审计链条完全保持一致。

案例 2：某商用车车企研发 PLM 客户端接入（C/S 架构，路径二）

• 现状：封闭 Windows 桌面客户端，无开放外部 HTTP 接口，但本地安装目录含 SDK 与脚本工具；工程师常需跨系统手工比对 BOM 与图纸；

• 方案：在工程师工作站本地部署适配服务，将 SDK 数据提取功能封装为结构化 CLI 命令，再由本地 stdio MCP Server 接入 Agent；

• 成效：复用客户端现存登录态与权限，实现图纸数据与物料状态的自动化核对，避免了高风险的数据库直连修改。

七、 实施推进步骤

• 资产盘点与分级：以“调用频次”与“改造难度”划定象限，优先从高频、低风险、接口相对完善的边缘业务切入。

• 协议标准化先行：严格遵守封装层只做 Schema 映射与数据透传的原则，降低耦合。

• 审计与安全闭环：在首个试点系统上线时即接入端到端调用链监控，并针对变更类操作强制实施二次人工授权。

当然，这篇文章仅仅是针对技术架构方面的尝试和各种概念性术语的解释，更多的内容我们后边一步步聊，慢慢唠嗑，欢迎关注。