Agent、MCP、Skill、Cli、Model 入门必备：老系统接入 AI 的概念地图与三条路径方案

主理人猫头虎微信: Libin9iOak

2985人浏览 · 2026-10-15 10:12:17

主理人猫头虎微信: Libin9iOak · 2026-10-15 10:12:17 发布

Agent、MCP、Skill、CLI、Model 入门必备：老系统接入 AI 的概念地图与三条路径方案

摘要：企业 AI 落地的第一道坎，不是选哪个大模型，而是Agent、MCP、Skill、CLI、Model 这五个概念到底谁调用谁。本文用一张"数字化团队"的比喻讲清五概念关系，拆解一次工具调用的完整接力，并给出老系统接入 AI 的三条路径（API 封装 / CLI 包装 / RPA 兜底）决策树，附 BS 与 CS 架构两个真实改造案例，帮你把"概念地图"直接变成"施工图"。

关键词：Agent、MCP、Skill、CLI、大模型、企业 AI 落地、老系统改造、Model Context Protocol

文章目录

Agent、MCP、Skill、CLI、Model 入门必备：老系统接入 AI 的概念地图与三条路径方案

一、事情的起因

客户是国内某大型整车集团研究院的 IT 团队。集团管理层给他们下了一个课题：「让 AI 深入老业务系统」。

注意这个提法——它说的是「深入」，而不是「上一套新的 AI 系统」。做过企业 IT 的人都懂，上新系统是采购问题，深入老系统是工程问题。管理层点了名，这道题躲不掉。

IT 同学犯难的地方，先出在概念层：Agent、Skill、MCP、CLI、Model，这些词现在满天飞。它们之间到底是什么关系，谁调用谁，标准和工具各是哪几个，平时没人系统讲过。

更实际的问题是，手里那些跑了十年八年的老系统——请假销假、PLM、各种内部平台——到底该从哪里下刀，AI 才用得起来。客户的需求很朴素：先讲明白，再谈怎么改。 于是有了这场交流和那份 42 页的 PPT。

[!NOTE]
本文适合：企业 IT 负责人、架构师、研发同学，以及所有需要向老板/客户解释"AI 怎么接老系统"的人。

二、五个概念构成一支团队

客户的第一个问题是，这些概念到底是什么关系。我们的办法是打比方：别背技术名词，把整套 AI 系统想象成公司新入职的一支数字化团队。

概念	团队角色	干什么
Model（大模型）	大脑	负责想，推理与生成引擎
Agent	数字员工	负责干，目标驱动、自主规划、调用工具的闭环执行体
Skill	岗位技能手册	负责会，把流程和经验封装成 Agent 能加载的技能包
MCP	万能转接头	负责接，连接 AI 与外部系统的开放标准协议
CLI	对讲机	负责说，指令清晰、回执明确、可记录的交互通道

2.1 Model 是大脑

它有参数量、上下文窗口、多模态这些属性。但大脑再聪明，没有手脚也干不了活——模型本身碰不到你数据库里的一行数据。

2.2 Agent 是数字员工

你给它一个目标，它自己拆任务、找工具、执行、看结果、再调整。感知、规划、行动、观察、再规划，这是个闭环。

[!WARNING]
最容易混的一点先说掉：Agent 是一套系统，Model 只是它的一个部件。 大模型不等于 Agent，就像发动机不等于一辆车。

2.3 Skill 是岗位手册

新员工入职发一本手册，通用员工就变成领域熟手。Skill 干的就是这件事：触发条件 + 操作流程 + 领域知识 + 工具清单，是工程化、可版本管理的流程资产。

它和 Prompt 不一样：Prompt 是随口叮嘱一句，Skill 是写进员工手册的 SOP。

2.4 MCP 是万能转接头

官方名字 Model Context Protocol，一个开放标准协议。一边是 Agent，一边是任意系统——数据库、API、文件、设备，不管什么插头，统一接口标准。这是整场的重点。

2.5 CLI 是对讲机

命令行接口，有双重身份：给工程师用是高效操作，给 Agent 用是结构化调用。

2.6 一个容易漏掉的嵌套关系

五个概念摆完，还有一对关系容易被漏掉：MCP 和 CLI 可以嵌套。

一个 MCP Server 的内部实现，常常就是封装了一个 CLI。最小的例子：把 git bash 封装成 MCP Server，Agent 通过 MCP 协议间接调用 git 命令。对 Agent 来说，它只看到 MCP 这个标准外壳，背后是 CLI、API 还是脚本，它不需要知道。

说得再直白一点：

CLI 管工具怎么执行，MCP 管怎么把工具标准地暴露给 AI。

记住这个嵌套关系，后面讲老系统改造会反复用到。

五概念关系总图

三、它们怎么协同

概念讲完，第二个问题很自然：用户说一句话，背后到底发生了什么？

就拿 「帮我查一下上周的请假记录」 这句话来说，这句话进去以后，背后是一场接力：

用户在 CLI（或随便什么对话入口）里说出这句话；
Agent 接到目标，把任务交给 Model 规划；
Model 判断这事要查 HR 系统，"员工手册"里有标准流程；
Agent 加载对应的 Skill，按流程找到该调用的工具，通过 MCP 协议向请假销假 MCP Server 发起调用；
MCP Server 再去调老系统的 REST API；
结果沿原路逐层返回，Agent 用人话告诉用户：你上周请了两天年假，剩余额度 8.5 天。

一次工具调用的完整接力

这里也把传统软件和 AI 里的术语做个映射，方便理解：

传统软件世界	AI 世界
微服务	Agent
OpenAPI / REST	MCP
内部 Wiki / SOP	Skill
SDK / 命令行	CLI

[!TIP]
看明白这张表，所谓 AI 架构就不再是黑话。它是你画了十几年的架构图，只是上面换了一层内容而已。

四、老系统怎么改

这是客户最关心的部分，也是管理层课题的核心。

4.1 先说扫兴的话：没有银弹

我们的第一个建议有点扫兴——没有银弹。方案取决于体检结果。

体检看四个维度：

API 开放程度——系统有没有可调用的接口？
文档完整性——接口有没有人写过文档？
鉴权体系——身份和权限怎么管？
变更风险承受度——这个系统动了会不会出事？

体检完走决策树，一共三条路：

路径一：API 封装为 MCP（首选）

系统有开放 API，直接在前面加一个 MCP Server 薄封装层。改动最小，最稳定，可灰度。

纪律只有一条：

封装层只做协议转换，不碰业务逻辑。

路径二：CLI 包装（次选）

没有 API 但有命令行、有运维脚本，把脚本封装成结构化 CLI，外面再包一层 MCP。

前面 git bash 的例子就是这条路的最小样本。技术上的要求是：CLI 输出要结构化，最好是 JSON，Agent 才消费得动。

$ mycli leave balance --user zhangsan

{
  "user": "zhangsan",
  "annual_leave": {
    "total": 15.0,
    "used": 6.5,
    "remaining": 8.5
  },
  "last_request": {
    "type": "年假",
    "days": 2,
    "status": "已批准"
  }
}

路径三：浏览器自动化 / RPA（兜底）

只剩一个网页界面，连脚本都没有，用浏览器自动化模拟人操作。

[!CAUTION]
能用，但脆——页面一改版就失效。它是过渡方案，别当终态。

三条路优先级从上到下，改造深度递减，脆弱性递增。

三条路径决策树

4.2 泼一盆安全的冷水

鉴权和安全，一案一议。

Agent 代替人去操作系统，身份怎么从用户传到 Agent 再传到系统？权限怎么收到最小？操作怎么审计？敏感动作要不要人工确认？

行业目前拿不出通用标准方案，每个系统都得单独评审。

[!WARNING]
谁跟你打包票说有现成方案，谁就没干过企业级落地。

4.3 怎么排序动手

画一张 「使用频次 - 业务价值」四象限图 ，从高频、低风险、有 API 的系统先动手。

理由很现实：

第一场仗必须赢，还得赢得便宜。

五、MCP 的实现形式

交流前客户做过功课，问我们 MCP 是不是有 stdio、HTTP、SSE 三种实现。

对，但不全对。

这里有个连很多技术文章都搞错的事实：MCP 官方规范里只有两种标准传输方式——stdio 和 Streamable HTTP。SSE 从 2025 年 3 月起就被取代了，是历史方案。

完整的版图分四类：

类别	实现形式	定位
官方标准	stdio	默认选项（本地）
官方标准	Streamable HTTP	默认选项（远程）
历史遗留	HTTP + SSE	只做存量迁移，别新建
社区扩展	WebSocket / WebRTC / 进程内 RPC	生态在标准之外长出来的，按需采用

还有一类最容易混：MCP Gateway、Proxy、托管 MCP——它们属于部署架构，和新协议无关，偏偏最容易跟传输方式搅在一起。

一个认知先立住：

MCP 是传输无关的，协议逻辑不变，变的只是消息怎么跑腿而已。

MCP 实现形式完整分类

5.1 stdio

宿主程序直接拉起本地子进程，走标准输入输出。本地开发和桌面 Agent 的标准姿势，代价是单机单客户端，信任关系只在进程级。

5.2 Streamable HTTP

单个 HTTP 端点，POST 发请求，GET 建流收推送，支持会话保持和断线恢复，配 OAuth 2.0。企业内集中部署、多团队共享，官方推荐的远程方式只有它。

5.3 SSE

双端点的早期方案。见到它只有一个动作：

规划迁移。

5.4 WebSocket

全双工低延迟，典型场景是浏览器桥接——比如 Agent 连 Chrome 扩展做浏览器自动化。代价是负载均衡要做粘性会话，企业防火墙可能拦升级握手。

5.5 选型四句话

选型可以压成四句话：

本地开发用 stdio；
企业共享用 Streamable HTTP 加 OAuth；
SSE 只做存量迁移；
WebSocket 留给实时和浏览器场景。

六、两个实战案例

光讲方法论客户不认，得有实战。我们选了两个：一个 BS 架构，一个 CS 架构。

6.1 案例一：BS 架构——某头部车企请假销假系统（走第一条路）

系统现状：Java Web 系统，BS 架构，有 REST API，HR 高频场景。
痛点很具体：员工查个假期余额要登录系统点五步，HR 每月还要人工对账。
改造做法：REST API 前面加一个 MCP Server，Streamable HTTP 集中部署，鉴权对接企业 SSO——老系统一行代码没动。
改完效果：员工在对话窗口说一句"帮我请明天下午半天年假"，五步变成一句话。

6.2 案例二：CS 架构——某欧洲商用车企 PLM 系统（走第二条路）

系统现状：传统桌面客户端，CS 架构，没有开放 REST API，但客户端自带 API 和 SDK。
痛点：数据孤岛，工程师在系统之间人工搬运 BOM 和图纸信息。
改造做法：在 PLM 客户端旁边部署一个本地封装服务，把客户端 API 包装成结构化接口，再包一层 MCP，会话和权限沿用客户端已有的登录态。

BS 架构案例：请假销假系统

CS 架构案例：PLM 系统

6.3 三条可复用的经验

两个案例对照着看，有三条经验可以复用：

先体检再选路径——别拿着锤子找钉子；
封装要薄，不碰业务逻辑——封装层越薄，项目死得越慢；
鉴权一案一议——把它写进项目计划，别当意外处理。

七、效果与复盘

交流结束后，客户给了好评。用他们的话说，这场分享把 Agent、MCP 这些词的关系讲清楚了，三档路径的决策树拿回去就能对着自己的存量系统用。

我们自己复盘，一场对客户的技术交流做到这一步就算及格。标准只有一个：

对方听完觉得：这事我们自己就能干。

八、总结

问题	一句话答案
五概念什么关系？	大脑（Model）+ 员工（Agent）+ 手册（Skill）+ 转接头（MCP）+ 对讲机（CLI）
老系统怎么接？	体检后走三条路：API 封装 → CLI 包装 → RPA 兜底
MCP 怎么选型？	本地 stdio，远程 Streamable HTTP，SSE 只迁移
最大的坑是什么？	鉴权与安全没有通用方案，一案一议

AI 落地企业，拼的从来不是模型参数，而是把老系统接进来的工程能力。概念地图已经画好，接下来，看你的施工图了。