对比背景与核心概念解析
在企业推进数字化转型的进程中，管理层往往提出“让AI深入老业务系统”的诉求，而非简单采购一套独立的AI系统。前者是复杂的工程改造问题，后者仅是软件采购问题。对于技术团队而言，要在跑了十年八年的内部请假销假、PLM等老系统上引入AI能力，首先面临的是概念认知混淆与接入路径选型难题。
在展开路径对比之前，需明确整个AI技术栈中五个核心概念的定位与职责。我们可以将整套AI系统抽象为企业新入职的一支数字化团队：
- Model（大模型）：扮演“大脑”，负责推理与内容生成。尽管具备强大的多模态和上下文处理能力，但模型本身无法直接触碰企业数据库中的数据。
- Agent（智能体）：扮演“数字员工”，负责闭环执行。接收目标后，自主进行任务拆解、工具查找、执行反馈与策略调整。
- Skill（技能）：扮演“岗位技能手册”，将业务流程与经验封装为Agent可动态加载的技能包。
- MCP（模型上下文协议）：扮演“万能转接头”，是连接AI与外部系统的开放标准协议，负责标准化数据交换。
- CLI（命令行接口）：扮演“对讲机”，提供指令清晰、回执明确、可记录的交互通道。
明确了概念关系后，真正的工程挑战在于：如何让Agent通过MCP等协议，跨越技术代沟，调用老系统中的能力？目前业界主流的接入路径主要分为三种：API封装、CLI包装与RPA兜底。这三者在技术架构、改造成本与适用场景上存在显著差异。
三条接入路径的相同点分析
尽管实现机制截然不同，但这三条路径在目标与基础能力上具有以下共同点：
- 目标一致性：均旨在打破AI大模型与传统业务系统之间的隔离墙，使Agent能够读取历史数据或触发业务流程。
- 工具化封装：无论底层是API、CLI还是UI操作，最终对Agent而言都是一个可调用的工具。通过MCP等标准协议转换，Agent只需声明工具名称与参数即可调用。
- 闭环反馈机制：三条路径都必须向Agent返回执行结果，以便大模型进行下一步推理与规划。
核心差异分析
在具体工程实践中，三条路径的差异决定了技术团队的选型方向。
1. 技术架构与接入方式
- API封装：直接对接老系统现有的内部接口，或通过中间件层将数据库操作封装为RESTful/gRPC接口。它属于系统级直连，架构最轻量。
- CLI包装：在老系统所在的服务器上编写命令行脚本，通过标准输入输出进行交互。Agent通过SSH或本地进程调用CLI，CLI再操作底层系统。它属于进程级交互。
- RPA兜底：不改动老系统任何底层代码，通过自动化脚本模拟人类在系统界面上的点击、输入与读取操作。它属于表现层操作。
2. 接入难度与改造量
- API封装：如果老系统已有完善的API，接入成本极低；若没有，需深入老系统代码逻辑开发新接口，改造量最大，风险也最高，可能引发原有系统稳定性问题。
- CLI包装：介于中间状态。无需改动前端代码，只需编写后端脚本，对老系统的侵入性较小，但受限于系统后端已有的命令行能力或可编程接口。
- RPA兜底：对接入层零改造。无需老系统开发团队配合，只要系统有可视化界面即可操作，但前期需要配置自动化流程规则，后期维护依赖于界面元素的稳定性。
3. 性能表现与可靠性
- API封装：性能最优，吞吐量大，延迟最低。接口调用稳定，且易于做异常重试与幂等控制。
- CLI包装：性能中等。受限于脚本执行效率与进程启动开销，不适合高并发场景。可靠性依赖于服务器环境与脚本健壮性。
- RPA兜底：性能最低，延迟最高。由于需要解析DOM元素或模拟鼠标键盘，执行耗时往往是前两者的数倍至数十倍。且极易因前端UI改版而导致流程中断，可靠性最差。
4. 适用场景与使用边界
- API封装：适用于有源代码维护能力、对性能要求高、需频繁调用的核心生产系统（如订单处理、核心数据库查询）。
- CLI包装：适用于无前端API但有后台运维入口的系统，或用于执行批量重启、日志清理、系统巡检等偏运维侧的场景。
- RPA兜底：适用于完全闭源、无法获取源码的SaaS系统或年代久远的陈旧CS架构系统。它是“最后手段”，当无法通过代码层面接入时才使用。
关键差异对比表格
| 对比维度 |
API封装路径 |
CLI包装路径 |
RPA兜底路径 |
| 交互层级 |
系统级/数据级直连 |
进程级/命令行交互 |
表现层/UI模拟 |
| 老系统改造量 |
高（需开发或重构接口） |
低（编写后台脚本） |
无（零代码改动） |
| 执行性能 |
高吞吐，低延迟 |
中等，存在进程开销 |
极低，耗时与UI复杂度正相关 |
| 稳定性与可靠性 |
高，支持完善的错误码与重试 |
中等，依赖脚本与系统环境 |
低，强依赖前端UI布局不变 |
| 运维成本 |
接口版本管理与鉴权维护 |
脚本权限分配与服务器环境依赖 |
UI变更即失效，需频繁维护流程 |
| 适用架构 |
现代Web系统、有DB直连权限的系统 |
内部运维平台、支持SSH的后台服务 |
闭源SaaS、老旧CS架构、无接口系统 |
典型场景选择与选型建议
基于上述差异，技术负责人在制定迁移方案时应采用条件化的选型策略：
- 核心业务高频场景：如企业内部PLM系统的数据检索与状态更新，对响应速度和稳定性要求极高。建议优先选择API封装路径。如果原生系统不具备API，建议由原厂或具备二开能力的团队进行接口适配改造。
- 运维与内部管理场景：如请假销假流程的后台审批触发、系统日志轮询等。若老系统提供了一定的后台命令行工具，可优先采用CLI包装。通过编写Python或Shell脚本作为Agent与系统间的桥梁，兼顾效率与低侵入性。
- 异构与黑盒系统场景：面对完全无法获取底层接口的第三方黑盒系统，或仅提供CS客户端的老旧平台，RPA兜底是唯一可行的路径。此时需接受其较高的延迟与维护成本，将其用于低频、非关键链路的操作。
迁移与使用注意事项
在将Agent通过MCP等标准协议接入老系统时，需特别关注以下工程风险：
- 安全与合规：API与CLI路径下，Agent可能获得直接操作底层数据的权限。必须建立严格的身份认证机制与最小化权限模型，限制Agent仅能执行预设范围的SQL或命令，避免自然语言意图被误解为破坏性指令（如误删数据表）。
- 日志与审计：无论是哪种路径，Agent的每一次工具调用都必须记录完整的输入参数与输出回执，确保所有AI驱动的操作可追溯，满足企业内部审计要求。
- 容错与降级：考虑到大模型可能存在的幻觉，调用工具时必须加入参数校验机制。对于RPA路径，需设计界面元素定位失败时的重试与告警机制，避免Agent陷入死循环。
总结
Agent、MCP、Skill、CLI与Model共同构成了AI接入企业业务的概念地图。在面对老系统改造时，没有一刀切的万能方案。API封装直击痛点但改造成本高；CLI包装折中平衡但受限于系统底层能力；RPA兜底虽能解决无接口难题但性能与稳定性堪忧。技术团队应客观评估自身老系统的架构现状、团队能力与业务场景性能要求，在一条主线中灵活组合多条路径，才能真正让AI深入并赋能老业务系统。