随着 AI Agent 进入企业业务系统，越来越多的团队开始面临一个实际问题：

如何让 AI 操作企业现有的业务系统，而不必重新开发一套系统？

比如，员工通过对话查询年假余额、提交请假申请；研发人员用自然语言检索 PLM 系统中的 BOM 和图纸；测试人员让 Agent 查询缺陷、创建测试任务，或者执行已有的自动化测试脚本。

这些需求都涉及 Agent、MCP、Skill、CLI 和 Model，但五者承担的职责完全不同。

本文结合 MCP规范，梳理 AI Agent 的执行架构，以及企业老系统接入 AI 的三种工程实现路径。

一、Agent、MCP、Skill、CLI、Model 分别负责什么？

先看五个概念在系统中的位置。

可以结合一个研发场景理解。

工程师提出需求：

“查询项目 A 最近一周的严重缺陷，并整理成测试报告。”

Model 负责理解要求，判断需要查询缺陷系统并生成报告。

Agent 负责组织任务，执行查询，获取数据，并在必要时再次调用模型。

Skill 可以提供缺陷分级规则、统计口径、报告模板等操作规范。

MCP Server 向 Agent 暴露缺陷查询工具，底层连接 Jira、禅道或企业自研系统。

CLI 则可能负责执行报告生成脚本，或者调用已有的内部命令行程序。

这里需要区分两个容易混淆的地方。

第一，Agent 不等于 Model。

Model 可以生成工具调用请求，但实际的权限校验、工具执行、结果回传通常由 Agent 所在的应用程序或运行时负责。

第二，MCP 和 CLI 可以配合使用，但彼此没有强制依赖关系。

Agent 可以直接调用 CLI，也可以通过 MCP 调用封装了 CLI 的服务。MCP Server 的底层同样可以连接 REST API、SDK、数据库或其他服务。

二、一次 AI Agent 工具调用，后台经历了什么？

假设企业已经有一套人力资源系统，员工需要查询年假余额。

传统方式需要进入 OA，找到请假模块，查看剩余假期。

接入 AI Agent 后，员工只需要输入：

“帮我看看今年还剩多少天年假。”

后台可以按照以下流程执行。

1. 接收请求： Agent 接收到员工的自然语言指令，并结合当前用户身份和上下文构造模型请求。
2. 判断操作： Model 识别查询意图，生成调用 query_leave_balance 工具的请求。
3. 调用工具： Agent 运行时通过 MCP Client 向 MCP Server 发送工具调用，并传递必要参数和授权信息。
4. 访问系统： MCP Server 完成鉴权后，调用原有 HR 系统的 REST API。
5. 处理结果： HR 系统返回结构化数据，工具结果传回 Agent，Model 根据结果生成最终回复。

例如，HR 系统返回：

{
  "leave_type": "annual",
  "remaining_days": 6.5,
  "unit": "day"
}

Agent 最终回复：

“你今年还剩余 6.5 天年假。”

如果任务继续变成“帮我申请明天下午半天年假”，系统还需要执行日期校验、权限检查、提交确认和业务 API 调用。

查询与写入必须区分。 查询可以在完成授权后直接返回，提交申请、修改数据、删除记录等操作，则需要根据风险级别增加用户确认与审计环节。

这里的重点是：模型提出行动建议，运行时负责执行，企业业务系统保留最终的权限与业务规则判断。

三、企业老系统接入 AI，有三条改造路径

大多数企业已有 CRM、ERP、OA、PLM、测试管理平台或内部研发系统。

这些系统开发年代不同，开放能力也不同。有些提供完整 API，有些只能使用 SDK 或命令行，还有一些只有 Web 页面。

因此，需要先评估系统的现有接口能力，再决定 Agent 如何接入。

路径一：已有 API，优先封装 MCP Server

如果老系统已经提供 REST API 或其他稳定服务接口，改造成本通常较低。

基本结构为：

AI Agent → MCP Server → 业务 API → 原系统

MCP Server 负责定义工具名称、参数结构、返回格式和调用适配逻辑。

例如：

工具名称：query_defects

输入参数：
project_id
severity
start_date
end_date

输出结果：
缺陷列表
缺陷数量
状态分布

企业原来的缺陷管理系统继续处理查询、权限及业务规则。

MCP Server 只增加 AI 可以识别和调用的标准工具接口，避免重复实现成熟业务逻辑。

路径二：没有开放 API，通过 SDK 或 CLI 接入

一些较早的桌面系统没有 REST API，但提供 Java SDK、C++ SDK、客户端插件或批处理命令。

可以增加本地适配服务：

AI Agent → MCP Server → SDK / CLI → 老系统

比如 PLM 系统本身支持通过 SDK 查询 BOM，那么可以将查询能力封装成一个结构化工具。

关键要求是输入输出必须清晰、稳定。

尤其是 CLI，需要处理执行超时、退出码、错误输出、命令注入和进程权限问题，不能允许模型自由拼接任意系统命令。

路径三：只有界面，通过浏览器自动化或 RPA 接入

如果系统没有可用 API，也没有 SDK 或 CLI，但保留了可操作的 Web 页面，可以使用 Playwright、浏览器自动化或者 RPA。

结构为：

AI Agent → 自动化执行服务 → 系统界面

这种方式适合过渡改造和低风险任务。

但是页面结构变化、登录过期、弹窗、网络延迟都可能影响执行稳定性。

对于高频且重要的业务流程，建议逐步建设稳定接口，减少对界面操作的依赖。

三种方案可以这样比较：

表中的成本和稳定性是一般工程判断，具体还要结合权限体系、接口文档、系统部署方式及业务风险。

四、MCP 2026 最新规范，发生了哪些变化？

这一部分需要特别关注，因为不少 MCP 入门资料仍然采用 2025 年的协议结构。

2026 年 7 月 28 日，MCP 正式发布新版本 2026-07-28，对协议状态管理、远程调用、授权以及扩展机制进行了调整。

1. MCP 仍然以两种标准传输方式为主

注意，SSE 是一种通用网络通信技术，废弃的是早期 MCP 的 HTTP+SSE 传输方案，并不意味着所有 SSE 技术都被淘汰。

另外，MCP Gateway、Proxy 和托管 MCP 属于服务部署与治理方案，不能与 stdio、Streamable HTTP 并列为传输协议。

2. 2026 版本移除了协议级会话

较早的 MCP 实现中，客户端通常需要初始化连接，并可能维护 Mcp-Session-Id。

2026-07-28 规范采用无状态协议核心。

每次请求携带自身所需的协议及客户端信息，不再依赖原来的初始化握手和协议级会话标识。

这让 MCP Server 更容易部署在普通 HTTP 负载均衡架构中。

不过，无状态只针对 MCP 协议核心，业务系统中的登录态、操作上下文和长任务状态仍然需要应用层自行维护。

3. 工具调用和授权能力进一步完善

新版规范增加了通过 HTTP Header 传递操作信息的机制，例如 Mcp-Method 和 Mcp-Name，方便网关进行路由、限流和授权控制。

同时加入多轮往返请求（MRTR），支持工具在执行过程中向客户端请求补充信息或用户确认。

Tasks 也作为扩展机制，为长时间运行的任务提供更明确的处理方式。

这类能力对企业 AI Agent 很重要，例如审批操作、长时间报表生成和批量研发任务。

4. Skill 与 MCP 可以进一步协作

Skill 通常以 SKILL.md 等文件组织操作说明、领域知识和执行流程。

2026 年的 MCP 生态也已经提供独立的 Skills 扩展规范，允许 MCP Server 向客户端发布 Skill。

这样，服务端除了提供工具，还可以同时交付工具的使用方法与领域操作规范。

但 Skills 扩展需要客户端与服务器共同支持，并非所有 MCP 产品都会自动具备这一能力。

五、案例一：企业请假系统如何接入 AI Agent？

以典型的 B/S 架构请假管理系统为例。

已有系统具备员工身份认证、假期余额查询、请假申请与撤销接口。

推荐保留原有业务系统，并增加 MCP Server。

架构如下：

企业对话入口 → Agent → MCP Server → HR REST API → 数据库

MCP Server 可以暴露三个工具：

员工通过 Agent 查询余额时，系统执行授权检查后可以直接返回结果。

申请或撤销假期时，需要校验用户身份、请假规则及相应操作权限。

企业原有的 SSO 可以承担身份认证，但仍需设计从 Agent 到 MCP Server、再到 HR 系统的身份传递和授权机制。

不能直接将 Agent 的服务账户权限当成员工本人的操作权限。

在涉及审批、销假、批量提交等场景时，还应保留人工确认和操作审计。

六、案例二：没有 REST API 的 PLM 系统怎么改？

PLM、CAD 和部分企业研发系统经常采用传统 C/S 架构。

这些系统可能已经运行多年，客户端封装了大量业务操作，但服务器并未开放通用 REST API。

如果客户端提供 SDK、插件接口或者批处理能力，可以使用本地 MCP Server。

基本结构为：

研发 Agent → 本地 MCP Server → PLM SDK/CLI → PLM 服务端

例如，工程师输入：

“查询产品 A 的 BOM 结构，以及最近一次变更记录。”

Agent 根据任务调用 BOM 查询工具。

MCP Server 使用已有 SDK 获取数据，再把结果转换成结构化内容返回。

首批工具可以选择：

• BOM 结构查询
• 图纸元数据查询
• 工程变更记录查询

建议优先建设只读能力，确认数据范围、访问权限与执行性能后，再考虑变更提交、版本更新等写入操作。

对于强依赖客户端登录态的系统，本地适配服务还需要明确进程隔离、凭据保护与会话失效处理策略。

如果 SDK 有严格的桌面运行环境或授权限制，MCP Server 也应部署在受支持的执行环境中。

七、AI Agent 接入老系统后，测试开发重点关注什么？

接口调用成功，只能说明基础链路连通。

企业还需要验证 Agent 能否在复杂输入、异常响应、权限限制和业务状态变化下正确执行。

建议重点覆盖以下六类测试。

尤其需要注意，MCP 解决的是标准化接入问题，并不会自动保证工具调用的安全性和业务正确性。

例如，Agent 调用了正确的请假工具，但传错了日期；或者正确查询了数据库，却读取了当前用户无权访问的数据。

这些问题都需要通过参数约束、服务端权限检查、执行审计及自动化评测共同控制。

对于写入类操作，还要重点检查重复提交和异常重试是否导致业务数据不一致。

八、企业老系统 AI 改造，建议先做最小闭环

一个企业往往有数十甚至上百个存量业务系统，没有必要一次性全部接入 Agent。

可以先选择一个高频、边界明确、风险较低的场景。

例如查询缺陷记录、获取研发文档、检索工单信息或查询员工假期余额。

第一阶段完成系统接口梳理、MCP 工具封装和 Agent 调用验证。

第二阶段补齐身份认证、权限控制、错误处理、日志追踪与自动化评测。

第三阶段再逐步增加写入操作、复杂流程编排、多系统协作及统一治理能力。

从工程实现来看，原有 API、SDK、CLI 和业务规则仍然具有价值。MCP 可以复用这些能力，Agent 则根据用户目标组织工具调用，Skill 负责沉淀业务操作规范。

最终形成一条清晰的执行链路：

用户提出任务 → Agent 组织执行 → Model 辅助决策 → MCP/CLI 调用系统 → 返回结果并验证。

对于有大量存量系统的企业，这是一条可以渐进实施的 AI Agent 集成路线。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。