存量系统 Agent 化，物理上到底怎么「接」

上一篇 把战略层讲清了：API 让能力「接得上」，Skill 让能力「用得对」，MCP 让能力「放得开」；改造的第一步不是改系统，而是把人脑里的使用方法交给 Agent。

但真到动手那天，团队问的不再是「该不该建 MCP」，而是更具体的问题：

• 我们这个跑了 8 年的老系统，接口文档残缺，怎么接？
• 那个连源码都没有的内部工具，要不要等业务方开放 API？
• 一个完整业务任务，从识别场景到上线试点，到底分几步？

这篇就是回答这些问题的。它不重复上一篇的战略判断，只讲落地——三类技术接入方式怎么选、一个系统的六步接入法。

先明确一个容易混的点：上一篇的「三条路径」（Skill+脚本 / 仅 MCP / Skill+MCP）是按抽象层级分的，回答「业务知识以什么形态提供给 Agent」；这一篇的「三类接入方式」是按技术路径分的，回答「Agent 物理上怎么够到存量系统」。两者是正交维度：

                 按抽象层（上一篇）       按技术路径（这一篇）
                 ───────────────        ─────────────────
Skill 知识层      ← Skill 决定            （与下面三类正交）
能力暴露层        ← MCP / 脚本适配决定     API/RPC  |  UI自动化  |  数据层/事件
系统能力层        ← 原有 API 决定          （存量系统本身）

也就是说，无论你选 Skill+脚本还是 Skill+MCP，底下到底用 API、UI 自动化还是数据层接入，是这一篇要决定的事。

一、先校正视角：从「系统功能」到「Agent 可调用能力」

讲三类接入方式之前，先校正一个视角。这个视角不校正，后面所有方法论都会跑偏。

传统系统的能力组织方式是这样的：

用户 → 页面 → 系统功能

系统围绕页面、菜单、表单组织能力，人负责理解流程、寻找功能、填字段、把多个系统串起来。Agent 化之后，链路变成：

用户目标 → Agent 理解与规划 → 调用多个系统能力 → 返回执行结果

用户表达目标，Agent 负责理解规划，业务系统继续负责确定性执行，最后返回结构化、可验证的结果。

背后是三个转变：人找系统功能 → Agent 根据任务找能力；人在多系统间串联 → Agent 编排多个业务能力；系统只服务页面 → 系统同时服务页面、流程和 Agent。

关键判断是：

存量系统不需要被重建，而是需要在其之上建设一层「Agent 可调用能力」。

这层能力至少要满足四个要求：

上一篇讲的 Skill 解决的是「可描述」，这一篇要讲的接入方式，加上下一篇 的治理建设，解决的是「可授权、可审计、可评估」。

二、三类接入方式：按技术路径分

方式一：API / RPC 挂载法——最正统、最稳健

把存量系统现有的后端接口（RESTful API、gRPC、Dubbo 等），经过语义补充、权限治理和协议适配后，封装为 Agent 可调用的 Tools 或 Function Calling。

实现要点：

• 接口标准化：通过 OpenAPI Specification 或 MCP 协议导出接口定义，补充清晰的语义描述——参数含义、返回值格式、适用场景、触发条件、异常说明；
• 中间网关层：构建 Agent Gateway，统一负责鉴权透传、流量控制、异常降级、协议转换、调用审计（把 LLM 产生的结构化 JSON 转成后端 RPC 报文）；
• 工具语义封装：不要把底层接口原样暴露给 Agent，而是按业务动作封装为更稳定、更易理解的工具。

适用系统：核心业务系统、接口文档较完备、有运维支持、业务操作需要稳定性和审计的项目。

优点：稳定性高、响应快、执行准确，容易做权限控制、审计、容量管理和故障治理。

风险：需要梳理和维护 API 语义，需要业务和技术团队共同确认工具边界；对完全无 API 的老旧系统无法覆盖。

判断原则：核心业务能力优先走这条路。只要系统有接口基础，且业务操作涉及核心数据或关键流程，就应优先选 API/RPC 挂载法。

方式二：UI / UI-Automation 胶水法——无侵入、救急专用

当存量系统极其古老（VB/Delphi 桌面客户端、无源码 Web 系统），或业务方短期不开放 API 时，通过视觉或 UI 自动化方式接入。

实现要点：

• RPA / Web 自动化：Puppeteer、Playwright、Selenium 或传统 RPA，让 Agent 识别页面 DOM 树，或通过坐标、控件、脚本执行点击录入；
• GUI Agent / Visual Agent：结合多模态大模型与 OCR，让 Agent 直接「看」系统截图，定位按钮、输入框、表格，模拟人工操作；
• 流程脚本化：把人工频繁复制粘贴、跨系统搬运信息的流程，沉淀成可回放的自动化步骤。

适用系统：无 API 遗留系统、无法改造的老旧系统、跨多系统频繁复制粘贴的低效流程、低频低风险的短期补位场景。

优点：零代码侵入，不需要存量系统方做任何改动，启动快。

风险：页面元素或 UI 稍变就失败，时延高，并发能力差，审计和回放成本高。

判断原则：只作为过渡桥梁，不要当核心长期架构。可以先用它把人工低效流程跑起来，但别让它长期承载高风险核心交易。

方式三：数据层 / 事件驱动注入法——旁路式、适合分析与被动响应

不走前端 UI，也不一定同步调 API，而是从数据流或消息队列层面接入，让 Agent 扮演后台智能观测者或异步处理者。

实现要点：

• CDC（Change Data Capture）：通过 Debezium、Canal 等监听存量系统数据库 Binlog，数据变化时（比如新增异常订单）触发 Agent 做风险分析、自动提醒或后续处理；
• 消息订阅：Agent 挂到 Kafka、RabbitMQ 等消息总线上，接收业务事件，处理完把结果发回总线或写回业务库；
• 数据镜像 + RAG：把只读库、日志、文档、知识库定期同步到向量数据库，供 Agent 做复杂数据分析、自然语言查询、报告生成。

适用系统：异步审批、风险预警、报表生成、经营分析、智能日志分析、故障归因。

优点：不把 Agent 推理延迟放进同步业务请求，通常能降低对主流程的耦合，适合旁路增强。它仍会消耗 Binlog、复制、网络、存储和下游计算资源，需要通过限流、隔离和容量测试控制对源系统的影响。

风险：无法处理强时效、强同步的交互，不适合需要用户实时等结果的核心操作。

判断原则：分析、预警、监控、异步处理类场景优先考虑。它不解决「实时操作系统」的问题，但非常适合让 Agent 成为后台智能观测者。

三类方式对比

一句话：核心能力走稳健接口，老旧系统先低侵入补位，分析预警类场景走旁路解耦。不要一刀切。

三、一个系统的六步接入法

讲清接入方式之后，看一个具体系统从 0 到 1 接入 Agent 的完整流程。核心原则是：先确定业务场景，再拆任务、盘能力，最后进入工具封装和治理建设。接入工作不从「改哪个接口」开始，而从「要完成什么业务任务」开始。

第一步 识别高价值场景
  ↓
第二步 拆解业务任务
  ↓
第三步 盘点系统能力
  ↓
第四步 封装 Agent 工具
  ↓
第五步 增加控制和治理
  ↓
第六步 试点、评估、复制

第一步：识别高价值场景

原则：先找任务，不要先找系统。筛选标准——发生频率高、跨系统操作多、规则相对明确、人工耗时较长、执行结果容易验证、风险可控。

第一阶段优先选「高频、明确、低风险」的场景，不宜从复杂决策或高风险交易场景开始。

第二步：拆解业务任务

把一个完整任务拆成：

意图理解 → 信息查询 → 业务判断 → 系统操作 → 结果确认

一个可 Agent 化的任务，通常不是单一工具调用，而是一组可拆解、可编排、可治理的步骤：查询相关对象与上下文、汇总历史记录、根据业务规则判断、创建或更新业务记录、通知相关责任人、跟踪后续状态、返回执行结果和待确认事项。

这一步要明确：哪些步骤由 Agent 决策，哪些由确定性系统执行。Agent 负责理解、规划、编排；关键业务规则、数据校验和交易一致性仍由业务系统负责。

第三步：盘点系统能力

对每个任务步骤盘点系统能力：是否已有 API、是否已有工作流、是否只能通过页面完成、是否涉及敏感数据、是否属于高风险操作、是否需要人工审批。

最终产物是一张「任务—系统—能力」映射表。这张表是管理语言、业务流程和技术实现之间的桥梁：

这张表的真正价值在于让四类角色对齐：管理层看清边界、业务团队确认流程、技术团队落地接口、安全团队前置审查。没有它，Agent 改造很容易变成「技术团队自己改接口，改完业务方说不是我要的」。

第四步：封装 Agent 工具

核心原则：不要把底层接口原样暴露给 Agent。

底层可能有多个业务对象相关接口，但 Agent 工具应按业务语义重组。比如底层有 getOrder、getOrderItem、getOrderPayment 三个接口，Agent 工具应该封装成「查询业务对象完整视图」一个工具，而不是让 Agent 自己去拼。

工具设计要做到：名称清晰、参数尽量少、返回结果结构化、异常信息明确、调用结果可验证、幂等和重试机制完善。好的 Agent 工具不是「接口搬运」，而是面向业务任务重新组织后的能力单元。

第五步：增加控制和治理

接入 Agent 后，必须把权限、审计、审批放在架构里，而不是只依靠提示词。

为什么治理必须独立成层、内建在平台里，而不是塞进 prompt——这是整个 Agent 改造里最容易被低估、也最不能省的一环。这一步的展开留给下一篇，这里先记住一句话：

越是接入核心系统，越不能把治理寄托在提示词上——提示词会被绕过、会被注入、会被忽略。

第六步：试点、评估、复制

试点的目标不是证明「能不能跑通」，而是建立可量化评估：

试点成功后，应把工具规范、接入网关、鉴权、日志、评测、问题回收机制等沉淀为平台能力，再复制到其他系统——这正是下一篇 要讲的「从单点试点到全公司平台化」。

四、一句话收束

这一篇讲的是「接得上」——Agent 物理上怎么够到存量系统：

核心能力走 API，老旧系统用 UI 自动化补位，分析预警走数据层旁路；六步接入法的核心是「先找任务，再找系统」——从业务任务倒推系统能力，而不是从系统功能正推业务场景。

下一篇 是这个系列的收尾，讲单点跑通之后两件最容易被省的事：治理（为什么不能只靠提示词、三层职责怎么分）和推进节奏（从试点到平台化到规模化复制的三阶段）。

AI 工程化相关阅读

• 把存量系统交给 Agent，先想清楚 API、Skill、MCP 各是什么
• 单点跑通之后，怎么把 Agent 能力沉淀成全公司可复用
• MCP Server 选型决策树：从语言到审计，六个维度一次说清
• 当 MCP Server 只是”翻译”现成能力：FastMCP + Mem0 + Redis 的选型逻辑
• MCP 工具权限码怎么设计？read、write、dangerous 三层模型