简介：本文面向企业IT团队、架构师和运维人员，系统梳理Agent、Skill、MCP、CLI、Model五者的职责边界与调用关系，并围绕老业务系统接入AI的三条可行路径，给出从架构设计、环境准备、部署流程到上线验证与运维优化的完整实施方案，帮助读者把“让AI深入老系统”从口号落成可执行的工程部署任务。
本文要帮助读者部署的不是某一个孤立的AI应用，而是一套能够让企业存量业务系统获得AI能力的接入层。部署完成后，老系统无需推翻重写，即可通过标准化的交互通道被AI Agent调用，实现请假销假、PLM数据查询、内部平台操作等场景的智能化改造。
这套接入层的核心部署对象可以概括为三个部分：连接通道、技能封装、执行入口。连接通道解决“AI怎么触达老系统”的问题，技能封装解决“老系统的能力怎么被AI理解和使用”的问题，执行入口解决“谁在什么时机发起调用”的问题。三者共同构成一个可运行、可监控、可回滚的部署单元。
本文适合以下人群阅读：
在动手部署之前，必须先厘清五个高频概念的关系。这五个概念在各类技术讨论中频繁出现，但很少有人把它们的调用链讲清楚。用一个团队类比可以快速建立认知：
| 概念 | 团队角色 | 职责边界 | 部署时的具象形态 |
|---|---|---|---|
| Model（大模型） | 大脑 | 推理与生成，不做实际操作 | 模型服务端点，提供推理接口 |
| Agent | 数字员工 | 目标驱动，规划、调用、观察、调整的闭环 | 运行中的Agent服务进程 |
| Skill | 岗位技能手册 | 把业务流程封装成可加载的能力包 | 技能定义文件与配置 |
| MCP | 万能转接头 | AI与外部系统的标准连接协议 | 协议网关或适配服务 |
| CLI | 对讲机 | 指令清晰、回执明确的交互通道 | 命令行封装脚本或服务 |
关键理解：Model没有手脚，它不能直接碰数据库里的一行数据。Agent是那个有手脚的执行者，但它不是凭空会干活，必须加载Skill。Skill执行时需要和外部系统通信，MCP就是那个通信协议。而很多老系统没有现成的MCP接口，CLI包装就是把老系统“翻译”成MCP能理解的形式。这就是五者的真实调用链：Model → Agent → Skill → MCP → CLI → 老系统。
老系统接入AI的部署需求通常来自以下场景：
场景一：数据查询类系统。 比如PLM系统中的零部件信息、BOM结构、变更记录查询。这些系统有成熟的数据库和后端接口，但操作路径长、菜单层级深。AI接入的目标是让用户通过自然语言直接获取数据。
场景二：流程审批类系统。 比如请假销假、费用报销、采购申请。这些系统的核心是表单提交和状态流转。AI接入后，用户可以口述需求，由Agent代为填写和提交。
场景三：内部工具平台。 比如知识库检索、日志查询、工单创建。这些平台通常是Web形态的BS架构，接口规范性参差不齐。
根据老系统的技术架构和可改造程度，部署形态分为三种路径，这也是本次部署方案的核心决策点：
路径一：API封装——优先选择。 如果老系统已经具备可用的后端API（无论是RESTful还是其他形式），只需要在API之上增加一层MCP适配服务，将系统API包装成AI可理解的标准工具描述。这种方式的部署工作量最小，稳定性最高，是首选方案。
路径二：CLI包装——兼容过渡。 如果老系统没有规范的API，但有可访问的命令行工具、脚本入口或可自动化的客户端操作，可以通过CLI包装层将这些入口封装为标准化调用通道。CLI的优点在于它天然具备“指令清晰、回执明确”的特征，非常适合作为AI与老系统之间的对讲机。
路径三：RPA兜底——最后手段。 如果老系统既没有API，也没有CLI入口，只有图形界面，那么只能通过RPA（机器人流程自动化）来模拟人工操作。RPA部署成本高、稳定性差、维护复杂，应当作为兜底方案，能不用就不用。
老系统分为BS（浏览器/服务器）和CS（客户端/服务器）两种架构，AI接入的部署方式有本质区别：
BS架构：系统通过浏览器访问，后端通常有HTTP接口或可被自动化工具驱动的页面元素。部署AI接入层时，优先尝试从后端接口切入；若无接口，则通过页面自动化方式包装为CLI。
CS架构：系统需要安装客户端。这类系统的部署难度更高，因为客户端通常没有标准化的外部调用接口。可行的切入方式包括：利用客户端自带的命令行参数、批处理脚本，或者通过界面自动化工具操作客户端。
一次完整的AI工具调用，背后是一系列组件的接力。理解这个接力过程，是正确部署的前提。
以“用户问Agent：‘帮我查一下项目P102的BOM变更记录’”为例，完整链路如下：
第一步：Agent接收目标。 Agent收到自然语言指令，理解用户意图，确定需要调用“BOM变更查询”这个能力。
第二步：Agent匹配Skill。 Agent从已加载的技能包中检索，找到“BOM查询”技能，读取该技能的定义：需要什么参数、调用什么工具、返回什么格式。
第三步：Skill发起MCP调用。 Skill按照MCP协议规范，构造一个标准化的工具调用请求，发送给MCP网关。
第四步：MCP网关路由到CLI或API。 MCP网关根据配置，将标准请求转换为对老系统的实际调用。如果老系统有API，就直接调用API；如果只有CLI，就通过命令执行器触发CLI脚本。
第五步：老系统执行并返回。 老系统完成查询，返回原始结果（可能是JSON、表格文本或结构化数据）。
第六步：结果逐层回传。 CLI/API层将结果返回给MCP网关，MCP网关将结果封装为标准响应返回给Skill，Skill将结果整理成Agent可读的格式。
第七步：Agent观察结果并决策。 Agent检查返回结果是否满足用户需求。如果满足，生成自然语言回复；如果不满足，调整参数或换一个工具继续尝试。
第八步：Model生成最终回答。 Agent将最终的中间结果交给Model，由Model生成面向用户的自然语言回复。
基于上述链路，实际部署时需要准备以下组件：
| 组件 | 作用 | 部署要求 |
|---|---|---|
| 模型服务端点 | 提供推理能力 | 可调用的大模型API或本地推理服务 |
| Agent运行环境 | 承载Agent进程 | 具备任务调度和状态管理能力 |
| Skill注册中心 | 管理技能包 | 支持技能的上传、版本管理和启用/停用 |
| MCP网关 | 协议转换与路由 | 将标准MCP请求路由到不同后端 |
| CLI执行器 | 执行命令行脚本 | 隔离的执行环境，支持超时控制和输出采集 |
| 老系统连接器 | 对接具体业务系统 | 按系统分别实现，包括API客户端或CLI脚本 |
| 日志与监控 | 全链路可观测 | 记录每次调用的输入、输出、耗时和状态 |
MCP不是一个单一的软件组件，而是一套协议规范。在实际部署中，MCP的实现形式可以分为以下四类：
本地进程类：MCP网关作为Agent同机运行的后台进程，通过标准输入输出与Agent通信。适用于单机部署、工具数量较少的场景。
远程服务类：MCP网关作为独立服务部署，Agent通过HTTP或WebSocket远程调用。适用于多Agent共享工具、工具数量较多的场景。
嵌入式SDK类：在Agent代码中直接嵌入MCP客户端库，由Agent进程直接发起MCP调用。适用于开发能力强、希望精细控制调用行为的团队。
网关聚合类：在企业统一入口部署一个MCP聚合网关，将多个老系统的MCP端点注册到同一入口，由网关负责鉴权、限流、路由和审计。这是企业级部署最推荐的形态。
在开始部署之前，需要先完成资源规划。部署规模取决于三个变量：并发调用量、工具数量、老系统响应时间。
计算资源：MCP网关和Agent运行环境需要独立的计算实例。以中等规模（日均调用量千次级别）为例，建议准备至少2核4GB的基础资源。如果涉及本地模型推理，资源需求会显著上升。
存储资源：技能定义文件、配置文件、日志数据需要持久化存储。技能文件本身很小，日志数据按每天数百MB量级预留即可。
网络资源：MCP网关需要与老系统互通。如果是内网系统，网关必须部署在可访问老系统的网络区域内。如果需要跨网段访问，需要提前开通网络策略。
运行环境：Agent和MCP网关通常基于主流的服务端编程语言构建，需要准备对应的运行时环境。确保开发、测试、生产三套环境的运行时版本一致，避免“开发环境正常、生产环境报错”的问题。
配置管理：所有连接地址、端口、密钥、超时时间等参数，必须通过配置中心或环境变量管理，不要硬编码在代码中。生产环境配置与开发环境保持隔离。
密钥管理：调用模型服务需要API密钥，调用老系统需要系统账号凭证。这些密钥存储在独立的密钥管理模块中，通过权限控制限制访问范围，禁止明文写在配置文件里。
这是部署前最关键的工作。需要逐个确认每个目标系统：
摸底结果直接决定每条路径的可行性，必须先做这个工作再设计部署方案。
步骤1：创建运行环境。 在规划好的计算实例上安装运行时依赖，创建独立的运行账号，限制账号权限为最小必要权限。
步骤2：部署网关服务。 将MCP网关服务包上传到目标环境，解压到指定目录，修改配置文件中的监听端口、日志路径、超时时间等参数。
步骤3：配置认证策略。 为网关配置访问认证，确保只有合法的Agent才能调用网关。认证方式可以选择基于令牌的认证，令牌定期轮换。
步骤4：启动并验证网关。 启动网关服务，检查进程状态和监听端口，确认日志输出正常。通过健康检查接口验证网关是否可访问。
步骤1：准备CLI脚本。 将每个老系统的操作封装为独立的CLI脚本。每个脚本必须做到：接收明确的输入参数、返回结构化的输出结果、设置合理的退出码、包含超时控制。
步骤2：配置执行环境。 CLI执行器需要隔离的执行环境。如果多个CLI脚本之间有依赖冲突，需要使用独立的执行环境进行隔离。
步骤3：注册连接器。 将每个CLI脚本或API客户端注册为MCP网关的一个工具端点，定义工具名称、描述、参数格式和返回格式。
步骤4：单点联调。 在网关侧发起一次模拟调用，验证从网关到CLI到老系统的完整链路是否通畅，检查返回结果的格式是否符合预期。
步骤1：配置Agent运行参数。 设置Agent的模型连接信息、工具发现方式、最大调用轮数、单次调用超时等参数。
步骤2：编写Skill定义。 每个Skill需要包含：触发条件（什么时候用这个技能）、工具列表（调用哪些工具）、参数映射（用户输入怎么映射为工具参数）、结果处理逻辑（返回结果怎么整理）。
步骤3：注册Skill到Agent。 将Skill定义文件放置到Agent的技能目录或注册中心，触发技能加载，确认Agent能正确发现并加载该技能。
步骤4：端到端联调。 通过Agent发起一次真实的自然语言请求，观察完整调用链路：Agent是否正确匹配Skill、Skill是否正确调用MCP网关、网关是否正确路由到老系统、结果是否正确回传。
步骤1：启用调用日志。 在MCP网关层面记录每次调用的请求参数、返回结果、耗时和状态码。日志使用结构化格式，便于后续检索和分析。
步骤2：配置指标采集。 采集关键指标：调用总量、成功率、平均耗时、P95耗时、错误类型分布。指标数据推送至监控系统。
步骤3：配置告警规则。 设置告警阈值：调用成功率低于设定值触发告警、P95耗时超过设定值触发告警、网关进程异常退出触发告警。
超时配置：这是最容易出问题的配置项。老系统的响应时间不确定，模型推理本身也有延迟。需要分层设置超时：CLI脚本执行超时、MCP网关路由超时、Agent整体任务超时。三层超时时间应该是递进关系，内层超时小于外层超时，确保每一层都能在自己的超时范围内完成任务并返回明确的错误信息。
重试配置：对读操作可以适量配置重试，但对写操作（请假提交、审批操作）要极其谨慎。写操作重试可能导致重复提交，必须在业务层面具备幂等性时才能重试。
并发配置：CLI执行器的并发数要匹配老系统的承载能力。老系统如果只能处理5个并发请求，CLI执行器的并发上限就设为5，超出的请求进入队列等待，而不是直接打到老系统上。
认证失效风险：老系统的登录状态可能在运行中过期。CLI脚本需要检测认证失效并主动重新认证，而不是返回一个模糊的“操作失败”。
数据格式漂移风险：老系统的返回格式可能因为配置变更而改变。CLI脚本需要做好输出校验，不符合预期格式时返回明确错误，而不是把脏数据传给Agent。
权限越界风险：AI Agent可能会尝试调用未授权的工具。MCP网关必须实施工具级别的权限控制，每个Agent只能调用预先授权的工具列表。
部署完成后，按以下清单逐项验证：
服务可用性验证：确认MCP网关、Agent服务、CLI执行器全部处于正常运行状态，健康检查通过。
工具发现验证：确认Agent能正确发现并列出所有已注册的Skill和底层工具，工具描述准确反映实际能力。
单工具调用验证：针对每个老系统连接器，逐一发起直接工具调用，确认返回结果正确。
端到端调用验证：通过自然语言发起典型业务请求，确认从用户输入到最终回复的全链路正常工作。
异常场景验证：模拟老系统不可用、超时、返回异常数据等情况，确认系统能正确报错并有明确的错误提示，而不是静默失败。
每次部署必须保留旧版本的可回滚能力：
问题一：Agent找不到对应Skill。 排查方向：检查Skill定义文件是否放置在正确目录、格式是否符合规范、是否成功加载。查看Agent启动日志中是否有技能加载失败的记录。
问题二：MCP网关调用超时。 排查方向：分层定位超时发生在哪一段。检查CLI脚本自身的执行时间、老系统的实际响应时间、网关与老系统之间的网络延迟。逐段排除，不要笼统地认为是网关问题。
问题三：返回结果格式异常。 排查方向：检查老系统的实际返回内容是否与CLI脚本预期的格式一致。常见原因是老系统的输出格式发生了变化，而CLI脚本没有同步更新。
问题四：写操作出现重复提交。 排查方向：检查是否在非幂等操作上配置了重试。确认业务操作是否具备幂等性，如果不具备，移除该操作的重试配置。
问题五：认证状态频繁失效。 排查方向：检查老系统的会话保持策略，确认是否有其他因素导致会话被提前终止。调整CLI脚本的认证策略，从一次性认证改为按需认证。
熔断机制：当某个老系统连续失败达到阈值时，MCP网关应对该系统的工具调用启动熔断，短期内不再转发，避免持续放大故障。熔断恢复采用渐进式，先放行少量请求探活。
降级策略：对于非核心能力，在故障时可以返回降级提示，引导用户改用其他方式，而不是让Agent反复重试无望的操作。
结果缓存：对于查询频繁且数据变更不频繁的老系统接口，在MCP网关层增加结果缓存，减少对老系统的压力。缓存过期时间根据业务数据更新频率设定。
连接复用：MCP网关与老系统之间的连接尽量复用，减少反复建立连接的开销。对于HTTP接口使用连接池管理。
按需调用：Agent在规划任务时，优先使用缓存结果，避免重复调用。对于高成本的模型推理操作，在Skill设计时尽量减少不必要的调用轮次。
资源监控：定期审查计算资源的实际使用率，对长期低负载运行的实例进行规格缩减或合并部署。
最小权限原则：AI Agent所拥有的系统权限，应该严格限制在业务所需的最小范围内。不要赋予Agent超出当前Skill需求的额外权限。
审计追踪：记录每一次AI发起的系统操作，包括操作者、操作内容、操作时间和结果。审计日志需要独立存储，保留足够的追溯周期。
敏感数据管控：对于涉及敏感数据的查询结果，在返回给Agent和Model之前进行脱敏处理。明确哪些数据字段永远不应离开企业内网。
老系统接入AI不是配备一套新系统的问题，而是一个系统化的工程部署任务。本文的核心结论可以归纳为三点：
第一，概念关系是部署设计的基础。 Model是大脑，Agent是执行者，Skill是能力包，MCP是连接协议，CLI是交互通道。五者构成一条清晰的调用链：Model → Agent → Skill → MCP → CLI → 老系统。理解这个链路，才能知道每个组件部署在哪里、配置什么、监控什么。
第二，三条路径有明确的优先级。 API封装是首选，CLI包装是过渡，RPA兜底是最后手段。部署前的老系统摸底工作决定了每条路径的可行性，不能跳过摸底直接动手。
第三，上线只是开始，运维才是长期任务。 超时配置、重试策略、熔断降级、审计追踪、权限管控，这些运维措施决定了系统上线后能不能稳定运行。部署完成不等于事情结束，持续监控和优化才是让AI真正深入老系统的保障。