AI大模型逆向工程-将IT业务系统蒸馏为MCP能力接入到通用Agent平台

大家好，我是人月聊IT。今天继续讲IT系统蒸馏。即将已有业务系统蒸馏为 AI 可理解、可检索、可调用、可编排的 MCP 业务能力服务，并提供支持 MCP、A2UI 与统一认证的 AI Agent 对话端。基于整个需求和目标，完成一个最简单的POC端到端原型系统测试和验证。

1. 项目背景

传统业务系统主要面向人类用户设计。用户通过菜单、页面、表单和固定流程完成查询、录入、审批、统计等工作。随着大模型和 AI Agent 的发展，用户希望直接通过自然语言表达目标，由 AI 理解业务上下文并完成相应操作。

单纯把业务系统 API 注册为大模型工具并不能解决问题。API 文档通常只描述接口路径、参数和返回值，缺少业务对象关系、业务术语、流程状态、调用前置条件、权限约束、指标口径以及多个接口之间的协作关系。AI 即使能够调用接口，也可能出现选错接口、参数含义理解错误、调用顺序错误、越权执行或无法解释结果等问题。

本项目拟建设“业务系统蒸馏平台”。平台不读取和逆向分析业务系统源代码，而是以业务系统主动提供的材料为依据，包括：API 接口清单与说明、真实可调用的 API 地址、数据库设计说明书、用户操作手册、业务需求说明书以及相关流程和规则文档。平台对这些材料进行结构化解析、语义对齐、能力关联和人工校核，形成一套与真实 API 能力配合的业务参考元数据和领域元模型，并将其发布为标准 MCP Server。

任何支持 MCP 的 AI Agent 均可将蒸馏后的业务系统作为插件配置使用。平台同时提供一个内置 AI Agent 对话端，用于插件验证和实际业务使用。该对话端支持 Google A2UI 或兼容的声明式 UI 协议，可在对话过程中动态生成表单、确认页、列表和结果面板，并可通过统一认证和单点登录集成回原有业务系统。

2. 建设目标

2.1 总体目标

将每个接入的业务系统转换为一个标准化的“AI 业务能力插件”。插件既包含 AI 理解业务所需的语义，也包含执行业务所需的 MCP 工具，最终实现以下闭环：

用户自然语言意图
  -> 识别业务领域与任务类型
  -> 动态加载相关业务语义
  -> 发现并选择 MCP 能力
  -> 补齐或确认业务参数
  -> 调用真实业务 API
  -> 返回业务结果或动态 UI
  -> 全过程权限控制、审计和追踪

2.2 具体目标

1. 支持业务知识问答，包括业务流程、操作规则、术语、权限和状态含义。
2. 支持传统业务查询和智能问数，能够理解业务指标、维度、筛选条件和统计口径。
3. 支持通过 MCP Tool 调用真实业务 API，完成查询、录入、提交、审批等操作。
4. 支持多 API 协同，根据任务目标执行有依赖关系的接口序列。
5. 支持在参数不完整、数据需要选择或操作需要确认时动态生成 A2UI 界面。
6. 支持第三方 AI Agent 通过 MCP 标准接入，也支持平台内置 Agent 对话端。
7. 支持 SSO、用户身份透传、业务权限继承、敏感数据保护和完整审计。
8. 支持蒸馏产物版本化、评测、发布、回滚和持续更新。

2.3 非目标与边界

• 不扫描、不解析、不逆向业务系统源代码。
• 不让 AI 或 MCP Server 绕过业务 API 直接读写数据库。
• 数据库说明书仅用于补充业务对象、字段关系、约束和字典语义。
• 不替代原业务系统的最终权限判断、事务处理和核心业务校验。
• 不保证仅靠自动解析即可得到完全正确的元模型，关键语义必须允许业务人员审核确认。

3. 用户与使用场景

3.1 用户角色

3.2 典型场景

知识问答：用户询问“采购申请审批通过后还能修改吗”。Agent 检索采购流程、状态机和操作规则后回答，并引用对应依据，不调用业务 API。

业务查询：用户询问“查询我部门本月待处理的合同”。Agent 加载合同、部门和待处理状态的语义，调用查询工具，并将结果以列表或表格返回。

智能问数：用户询问“华东区今年各产品线的回款完成率”。Agent 解析指标定义、时间口径、区域和产品维度，调用统计 API；若原系统没有直接统计接口，只能在授权范围内组合查询能力并执行受控聚合，不得自行猜测口径。

业务录入：用户要求“新建一张差旅报销单”。Agent 确定必填字段和可选数据源，通过 A2UI 生成表单，用户填写并确认后调用写入工具。

多 API 协同：用户要求“为这个客户创建合同并发起审批”。Agent 先解析客户身份，再校验主数据和合同参数，创建合同，获取返回的合同 ID，最后发起审批。任何一步失败时按照编排策略停止、重试或执行补偿。

4. 输入材料与接入要求

4.1 必要输入

每个业务系统至少应提供以下材料：

1. API 接口清单，包含接口名称、用途、方法、路径、输入、输出、错误和认证方式。
2. 可实际访问的 API 基础地址，至少提供联调或测试环境。
3. API 调用凭证或可执行的认证流程。
4. 用户操作手册或业务需求说明书，至少有一类能够说明业务流程和规则的材料。
5. 接口责任人和业务责任人，用于处理语义冲突和联调问题。

推荐同时提供 OpenAPI 3.x 文件、Postman Collection、数据库设计说明书、数据字典、流程图、原型说明、角色权限表、错误码表和测试账号。

4.2 材料可信度

平台不通过源码验证接口实现，因此需要记录每项事实的来源、版本、提供人、更新时间和可信状态。建议采用以下优先级：

当前真实 API 响应 > 已确认的 API 文档 > 已确认的业务规则
> 当前用户手册 > 历史需求文档 > 未确认的数据库推导语义

当不同材料发生冲突时，平台不得静默覆盖，应形成“语义冲突项”，由 API 提供方或业务专家裁决。裁决结果需要保留依据和历史版本。

4.3 API 可调用性要求

每个拟发布为 MCP Tool 的 API 必须通过连接验证。验证内容包括 DNS 和网络可达性、TLS、认证、请求格式、必填参数、响应结构、错误结构、超时以及测试数据可用性。对于写接口，应优先使用专用测试环境或 dry-run 能力，禁止在未明确授权时向生产环境写入测试数据。

验证结果分为：未验证、验证通过、部分通过、验证失败、已停用。只有验证通过或经人工批准的部分通过接口才能进入正式插件版本。

5. 总体架构

系统分为六个核心子系统：

1. 材料接入与解析中心：接收文档、OpenAPI、数据字典等材料，完成文本提取、切片、结构识别和来源追踪。
2. 语义蒸馏与元模型中心：生成业务对象、术语、流程、规则、指标、能力关系，并提供人工审核工作台。
3. API 验证与治理网关：保存环境和认证配置，执行连通性测试、调用代理、限流、脱敏和审计。
4. MCP 构建与运行中心：把业务知识发布为 Resources，把 API 能力发布为 Tools，并提供检索与动态加载能力。
5. AI Agent 对话端：完成模型对话、MCP 插件配置、工具调用、任务编排、A2UI 渲染和人工确认。
6. 评测与运营中心：管理测试集、版本、发布、调用质量、失败分析和持续改进。

6. 业务元模型设计

6.1 元模型定位

业务元模型是本平台的核心产物。它不是数据库模型的简单复制，也不是 API 文档的重新排版，而是把“业务语义”和“可执行能力”连接起来的中间层。Agent 应能够通过元模型回答三个问题：当前用户想完成什么业务目标、需要理解哪些业务上下文、应该调用哪些能力以及如何调用。

6.2 核心实体

6.3 能力与 API 的关系

一个 Capability 表示面向用户的完整业务动作，可以映射一个 API，也可以映射多个有序 API。一个 ApiOperation 也可能被多个能力复用。例如“创建合同并发起审批”是一个组合能力，内部包含客户查询、合同创建和审批提交三个操作。

每个能力至少应包含：业务名称、自然语言示例、适用场景、输入语义、输出语义、前置条件、后置结果、关联对象、业务规则、风险等级、确认要求、关联 API、错误解释以及可选 UI Schema。

6.4 存储形式

结构化元数据建议存储于关系数据库，文档原文和解析结果存储于对象存储，检索切片和向量存储于搜索引擎或向量数据库。对象、规则、能力和证据之间应使用稳定 ID 关联，不能仅依靠文件名或自然语言名称。

发布时生成不可变版本快照，例如：

{
  "pluginId": "contract-system",
  "version": "1.3.0",
  "domains": ["contract", "invoice", "payment"],
  "mcpServer": "/mcp/contract-system/1.3.0",
  "modelRevision": "mr_20260917_001",
  "status": "published"
}

7. 蒸馏处理流程

7.1 流程阶段

1. 创建项目：登记业务系统、负责人、环境、数据级别和接入范围。
2. 材料上传：上传 API、数据库和业务文档，记录来源与版本。
3. 自动解析：提取章节、表格、接口、字段、对象、术语、规则和流程候选项。
4. 语义对齐：合并同义词，对齐数据库字段、业务属性和 API 参数。
5. 能力建模：将 API 归入业务域，建立能力、前置条件、结果和编排关系。
6. 冲突处理：展示材料间的不一致，由相关责任人裁决。
7. API 验证：配置环境和认证，执行请求验证并保存脱敏样例。
8. 人工审核：业务专家审核元模型，API 责任人审核调用定义。
9. 评测验收：执行知识问答、工具选择、参数填充、调用和安全测试。
10. 发布 MCP：生成版本化 MCP Server 配置并发布。

7.2 自动化与人工边界

大模型可以辅助提取候选术语、规则、对象和接口关系，但自动结果必须附带证据位置和置信度。涉及权限、金额、审批、删除、状态转换和统计口径的内容不得仅凭模型推断直接发布。平台应提供“待确认、已确认、已驳回、存在冲突”状态，并支持批量审核。

8. MCP Server 设计

8.1 MCP 能力分类

Resources 用于暴露系统概览、业务对象、流程、规则、指标和能力说明。Resource URI 应稳定、可版本化，例如：

business://contract-system/domain/contract
business://contract-system/process/contract-approval
business://contract-system/metric/payment-completion-rate
business://contract-system/capability/create-contract

Tools 用于执行真实业务能力。工具名称必须具有业务含义，例如 contract_query、contract_create_prepare、contract_create_commit，不建议直接使用数据库表名或模糊的 execute_api_01。

Prompts 可提供经过审核的任务模板，如“合同查询助手”“报销单创建助手”，但核心规则不能只写在 Prompt 中，仍应由元模型、网关和原系统共同约束。

8.2 Tool Schema

工具输入输出采用 JSON Schema，并保留业务级描述、枚举来源、格式、必填条件和敏感标记。示例：

{
  "name": "contract_create_prepare",
  "description": "校验创建合同所需信息并返回待补字段和确认摘要，不落业务数据",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customerId": {"type": "string", "description": "客户主数据 ID"},
      "amount": {"type": "number", "exclusiveMinimum": 0},
      "signDate": {"type": "string", "format": "date"}
    },
    "required": ["customerId", "amount"]
  }
}

8.3 动态语义加载

MCP Server 不应把整个业务系统文档一次性返回给 Agent。运行时先根据用户问题检索候选业务域、对象和能力，再加载相关规则、流程和 API 说明。检索应采用“结构化过滤 + 关键词检索 + 向量召回 + 重排”的混合策略，并优先返回已确认且与当前插件版本一致的内容。

返回的语义片段应携带资源 ID、标题、版本和证据来源，使 Agent 能够引用依据，也便于追踪错误语义来自何处。

8.4 MCP 运行方式

正式环境建议采用远程 MCP 服务，以 HTTP 流式传输方式部署在企业网关之后。每个业务系统可以独立部署 MCP Server，也可以由多租户 MCP Runtime 根据 tenantId + pluginId + version 动态路由。不同业务系统的凭证、索引、调用配额和审计数据必须隔离。

9. API 调用、验证与编排

9.1 调用网关

MCP Tool 不直接拼接 URL 调用外部系统，而是通过统一调用网关。网关负责：环境路由、身份和令牌交换、请求模板渲染、字段映射、超时与重试、幂等键、限流熔断、响应转换、敏感字段脱敏以及审计记录。

API 凭证必须保存在密钥管理系统中，元模型和 Agent 上下文中不得出现明文密码、固定 Token 或客户端密钥。

9.2 参数映射

业务语义字段与 API 参数之间建立显式映射。例如元模型中的 customer.id 可映射为请求字段 customerId。如果用户只提供客户名称，Agent 应先使用主数据查询能力获取 ID，不得假定名称可以直接作为 ID 传入。

字段映射应支持固定值、上下文值、用户身份值、上一步输出、格式转换和枚举转换。映射规则应可测试并随插件版本发布。

9.3 编排策略

平台同时支持两类编排：

• 确定性工作流：高频、高风险、顺序稳定的流程，由平台预先定义步骤、条件、失败策略和补偿动作。
• Agent 动态编排：低风险、长尾任务由 Agent 根据能力元数据生成计划，但每一步仍需经过策略引擎和参数校验。

工作流步骤至少包含 operationId、输入映射、成功条件、超时、重试、幂等策略和失败处理。跨系统操作通常无法依赖分布式事务，应采用 Saga 思路记录步骤状态，并在可行时配置补偿接口。不存在补偿能力时必须明确提示用户人工处理方式。

9.4 写操作协议

风险写操作建议采用两阶段调用：

prepare：校验参数、权限和业务条件，返回影响范围与确认摘要
commit：携带 prepareToken 和幂等键执行正式写入

prepareToken 应绑定用户、租户、能力、参数摘要和有效期，防止确认后参数被替换。删除、付款、审批通过等不可逆或高风险动作必须强制确认；普通查询可以直接执行。

10. AI Agent 对话端与 A2UI

10.1 对话端功能

内置对话端应支持模型配置、MCP 插件安装与启停、多轮会话、资源检索、工具调用过程展示、引用来源、执行确认、A2UI 渲染、结果导出和问题反馈。它既是正式使用入口，也是蒸馏插件的联调与验收工具。

10.2 A2UI 使用原则

A2UI 用于描述界面，不承载最终业务规则。服务端返回字段定义、候选值、校验信息和业务约束，对话端负责将声明渲染为受信任组件。动态 UI 仅允许使用预注册组件，如文本框、日期、金额、选择器、明细表、确认摘要和结果表格，禁止执行任意脚本或注入不受控 HTML。

典型交互如下：

用户提出创建任务
 -> Agent 调用 prepare 工具
 -> MCP 返回缺失字段、UiSchema 和选项数据源
 -> 对话端渲染 A2UI 表单
 -> 用户补充信息
 -> 再次 prepare 并生成确认摘要
 -> 用户确认
 -> commit 执行
 -> 返回详情卡片或结果页

UiSchema 需与能力版本绑定，并支持可见性条件、字段联动、远程选项、分页选择、只读字段、错误定位和国际化。最终提交前，所有数据仍需在 MCP 和业务 API 侧重新校验。

11. 统一认证与权限设计

对话端嵌入原业务系统时，优先采用 OIDC/OAuth 2.0 或企业现有统一认证协议完成单点登录。对话端获得用户身份后生成自己的会话，调用 MCP 时传递受签名保护的用户上下文。MCP 调用真实业务 API 时可根据目标系统能力选择令牌交换、委托令牌或服务账号加用户身份声明。

权限校验应至少包含四层：

1. 对话端判断用户是否可以使用某个业务插件。
2. MCP 策略引擎判断用户是否可以发现和调用某项能力。
3. 调用网关检查环境、风险等级、确认状态和数据范围。
4. 原业务系统执行最终角色权限和数据权限校验。

平台不得因为 Agent 已完成权限判断就跳过原系统校验。用户身份、租户、部门、角色、会话 ID、调用原因和链路追踪 ID 应贯穿整个调用链。

12. 安全、审计与治理

所有材料、检索内容、模型上下文和 API 返回值都需要进行数据分级。敏感字段应在元模型中标注，调用日志默认脱敏。模型只接收完成当前任务所必需的数据，避免把大批业务数据无差别放入上下文。

平台应记录：用户原始请求、模型选择的能力、加载的资源、工具参数摘要、确认记录、API 请求响应摘要、耗时、结果、错误和版本。高风险操作应支持独立审计查询和告警。

针对提示词注入，需要把业务文档视为不可信数据。文档中的指令性文本不能覆盖系统策略；工具调用只能来自已发布的能力清单；URL、方法和认证配置由服务端保存，模型不能自由构造任意目标地址。还应配置出站网络白名单、请求大小限制、频率限制、超时、熔断和异常调用检测。

13. 非功能需求

13.1 性能与可用性

• 普通知识检索建议 P95 小于 2 秒，不包含大模型生成时间。
• MCP Tool 的额外代理开销建议 P95 小于 500 毫秒，不包含业务 API 自身耗时。
• 支持流式返回长时间任务状态，避免前端长时间无反馈。
• 正式环境核心 MCP Runtime 和调用网关可用性目标不低于 99.9%。
• 支持水平扩展、无状态运行和故障实例自动摘除。

13.2 可维护性

• 元模型、API 定义、工作流、UiSchema 和策略均必须版本化。
• 插件发布后生成不可变快照，升级不影响正在进行的会话。
• 支持灰度发布、版本回滚和环境差异配置。
• 文档或 API 更新后只重建受影响的对象、能力和检索索引。

13.3 可观测性

使用统一 traceId 关联 Agent 会话、MCP 调用、网关请求和业务 API。提供成功率、工具选择准确率、参数补充次数、确认取消率、API 错误分布、平均耗时和用户反馈等指标。

14. 技术选型建议

平台后端可采用 Java/Spring Boot、Python/FastAPI 或团队现有技术栈，关键是模块边界和协议标准化。结构化元数据可使用 PostgreSQL，文档使用 S3 兼容对象存储，全文检索可使用 Elasticsearch/OpenSearch，向量检索可使用 pgvector 或独立向量数据库。任务解析和评测适合通过消息队列异步执行。

前端可采用 React 和成熟组件库实现蒸馏工作台及 Agent 对话端。A2UI 渲染层应建立组件注册表和 Schema 校验器，避免协议内容直接映射为任意前端代码。

MCP Runtime、模型供应商和检索引擎应通过适配层解耦。业务插件不应绑定某一个大模型，第三方 Agent 只要支持兼容的 MCP 协议即可使用。

15. 评测与验收

每个插件发布前必须建立测试集，至少覆盖：

建议为关键场景保存期望的资源加载结果、工具选择、参数、API 模拟响应和最终答案，形成可重复执行的回归测试。插件只有在业务专家、API 责任人和安全责任人完成相应审核后才能发布到生产环境。

16. 实施计划

完成材料上传、OpenAPI 解析、基础业务元模型、人工审核、单 API MCP Tool、知识 Resource、API 连通性验证和基础 Agent 对话端。选择一个接口规模适中、查询场景明确的业务系统试点。

我们来看下整体的可运行系统效果。

首先新建一个项目对某个业务系统进行蒸馏处理。业务系统提供相应的需求，数据库设计，接口清单等各种背景材料供AI分析。方便构建基于API接口的业务上下文信息。

进行系统蒸馏，蒸馏完成对API接口进行验证。

然后是发布MCP插件，并对MCP插件进行动态配置。

配置完成后接入AI对话。这个AI对话包括了通常的智能问答，也包括了知识问答，还包括了数据录入这种动态UI表单。

17. 总结

本项目的本质不是文档问答系统，也不是把 OpenAPI 机械转换成大模型函数，而是建设一个位于 AI Agent 与传统业务系统之间的“业务语义与能力中间层”。业务系统继续负责真实数据、事务、权限和最终规则；蒸馏平台负责从可信材料中建立完整业务语义，将语义与经过验证的 API 能力关联，并通过 MCP 标准向不同 Agent 输出。

在此基础上，第三方 Agent 可以把蒸馏后的系统作为 MCP 插件使用；内置 Agent 对话端则进一步提供 A2UI 动态交互、统一认证和原系统嵌入能力。最终用户不再需要记忆菜单和接口，而是能够用自然语言表达业务目标，由 AI 在明确权限、规则、确认和审计边界内完成查询、问数和业务协同。