MCP 思想与业务工具标准化封装
1. 对应简历段落
这篇文章对应简历中“借鉴 MCP 思想，将公司内部传统业务能力标准化封装为 AI 可发现、可调用、可治理的工具集合，统一接入保单、客户、产品、工单、保全、知识库等系统，降低大模型应用与存量业务系统的耦合”的经历。
面试时这部分不要只讲“MCP 是一个协议”。资深面试更关心你是否理解 MCP 背后的工程思想：工具描述标准化、上下文传递标准化、权限和审计标准化、资源访问标准化，以及如何把大量不统一的内部系统封装成稳定的 AI 工具层。
可以这样表述：
在内部 AI 工程化平台中，参考 MCP 的资源、工具和上下文抽象，将传统业务 API 封装为统一 Tool Registry。每个工具以标准 schema 描述能力、参数、权限、风险等级、调用方式和返回结构，AI 编排层通过统一协议发现和调用工具，从而避免每个 AI 应用重复对接保单、客户、产品、工单等系统。
这段经历的核心是“用标准化工具层把 AI 应用和传统系统隔离开”。
2. 业务背景
企业内部系统通常不是为大模型准备的。保险公司尤其明显：核心保单系统可能是多年前的 Java 单体，客户中心可能是 Dubbo 服务，产品中心可能有 REST 接口，影像系统可能是老 SOAP，保全后台可能只有页面操作，工单系统又有自己的一套权限和状态机。
如果每个 AI 应用都直接接这些系统，会出现几个问题。
第一，重复开发。AI 客服要查保单，研发助手也要查工单，运营助手也要查产品配置。每个系统各写一套适配器，维护成本很高。
第二，接口不稳定。传统 API 的字段、错误码、分页、鉴权方式不统一。模型应用如果直接依赖这些细节，会非常脆弱。
第三，安全难统一。不同团队各自接接口，权限校验、脱敏、审计、限流可能标准不一致，风险很大。
第四，模型难理解。内部 API 往往是面向系统调用设计的，比如 queryPolicyBaseInfoV2、getUwRuleByPrdAndPlan，模型不容易从这些名字判断何时使用。
第五，演进困难。以后要更换模型、增加 Agent、接入工作流平台，如果业务能力没有标准化，就会陷入大量点对点集成。
MCP 思想的价值在这里体现出来：不是简单追逐新协议，而是把企业内部能力抽象成模型和 Agent 能理解、能发现、能安全调用的工具与资源。
3. 核心原理
MCP 可以理解为大模型应用和外部能力之间的标准连接方式。它强调几个抽象：工具 Tool、资源 Resource、提示 Prompt、上下文 Context。落到企业业务系统里，可以转化为四个设计原则。
第一，能力描述标准化。每个业务工具都要有清晰名称、自然语言描述、输入 schema、输出 schema、错误语义和使用示例。模型不应该面对杂乱的内部接口，而应该面对“查询保单摘要”“查询续保失败原因”“创建客服工单”这种业务语义工具。
第二，调用协议标准化。无论底层是 REST、Dubbo、数据库代理还是页面自动化，对 AI 编排层都呈现统一调用接口。这样编排层不需要知道底层系统差异。
第三，上下文标准化。工具调用必须带上 userId、tenantId、orgCode、roles、conversationId、traceId、boundCustomerId、boundPolicyNo 等上下文。权限、审计和数据范围都依赖这些上下文。
第四，治理标准化。工具不是注册完就结束，还要有版本、风险等级、权限点、限流、熔断、审计、脱敏、下线策略和质量评测。
与普通 API 网关相比，MCP 思想下的工具层更强调“给模型使用”。普通 API 网关面向程序员，关注路由、鉴权、流量；AI 工具层还要关注工具描述是否清晰、参数是否模型友好、返回是否适合生成回答、错误是否可解释、是否能参与多轮上下文。
所以在面试中可以说：我们没有原样暴露内部 API，而是建立了面向 AI 的业务工具抽象层。
4. 项目落地
项目落地可以拆成三层：Tool Registry、Tool Adapter、Tool Runtime。
Tool Registry 是工具注册中心，保存工具元数据。字段包括 toolName、displayName、description、inputSchema、outputSchema、riskLevel、permissionCode、ownerSystem、ownerTeam、version、timeoutMs、rateLimit、resultPolicy、enabled、examples。注册中心可以先用配置文件，后续演进成数据库和运营后台。
Tool Adapter 是底层适配器，把不同业务系统封装成统一工具。例如 PolicyToolAdapter 调用保单系统，CustomerToolAdapter 调用客户中心，TicketToolAdapter 调用工单系统，OpenClawToolAdapter 调用页面自动化流程。适配器内部处理 RPC、REST、SOAP、参数转换和错误码映射。
Tool Runtime 是运行时，负责接收 AI 编排层的调用请求，做 schema 校验、权限校验、风控、调用执行、结果脱敏、审计和可观测性。它对上提供统一 execute(toolName, arguments, context) 接口。
一个工具定义示例：
{
"name": "policy.querySummary",
"description": "根据保单号查询当前用户权限范围内的保单摘要，包括产品名称、保单状态、缴费状态和续保提示。",
"riskLevel": "READ_PRIVATE",
"permissionCode": "POLICY_SUMMARY_QUERY",
"inputSchema": {
"type": "object",
"properties": {
"policyNo": {
"type": "string",
"description": "保单号"
}
},
"required": ["policyNo"]
},
"resultPolicy": {
"maskFields": ["mobile", "idNo"],
"allowFields": ["policyNo", "productName", "status", "payStatus", "renewalHint"]
}
}
这种定义比直接暴露 queryPolicyDetail 接口更适合模型。它明确告诉模型什么时候用、需要什么参数、能返回什么信息，也告诉工具层如何治理。
在 Java 工程中，可以用 Spring Boot 做工具运行时。工具适配器实现统一接口，注册中心在启动时加载工具定义。AI 编排服务需要调用工具时，先从 registry 读取当前用户可见工具，把 schema 提供给模型；模型返回 tool call 后，再由 runtime 执行。
5. 流程或伪代码
public interface BusinessTool {
String name();
ToolResult invoke(JsonNode arguments, ToolContext context);
}
public ToolResult execute(String toolName, JsonNode args, ToolContext ctx) {
ToolDefinition def = toolRegistry.find(toolName)
.orElseThrow(() -> new IllegalArgumentException("Unknown tool: " + toolName));
if (!def.enabled()) {
return ToolResult.failed("工具已下线");
}
schemaValidator.validate(def.inputSchema(), args);
permissionChecker.check(ctx.user(), def.permissionCode(), args);
riskGuard.check(def.riskLevel(), args, ctx);
BusinessTool adapter = adapterFactory.get(toolName);
long start = System.currentTimeMillis();
try {
ToolResult raw = adapter.invoke(args, ctx);
ToolResult safe = resultPolicy.apply(def.resultPolicy(), raw);
auditLogger.success(def, args, safe, ctx, System.currentTimeMillis() - start);
return safe;
} catch (BusinessException ex) {
ToolResult failed = errorMapper.toToolResult(ex);
auditLogger.failure(def, args, failed, ctx);
return failed;
}
}
这个运行时把所有工具调用都放在同一个安全管道里。新增工具时，业务团队只需要提供工具定义和适配器，不需要每个 AI 应用重复实现权限、脱敏和审计。
从 AI 应用视角看，流程是：
- AI 编排层根据用户和场景向 Tool Registry 请求可用工具。
- Registry 返回模型可理解的工具 schema。
- 模型选择工具并生成参数。
- Tool Runtime 校验并执行。
- Tool Adapter 调用真实业务系统。
- Runtime 脱敏、审计并返回结构化结果。
- 模型基于结果生成自然语言回答。
6. 安全边界
第一，工具发现边界。模型只能看到当前用户、当前应用、当前场景允许的工具。高风险工具默认不可见。
第二，资源访问边界。MCP 思想里的 Resource 在企业场景中可能是知识文档、保单摘要、工单详情、影像材料。资源读取必须做权限和字段控制。
第三，协议边界。AI 应用不能绕过 Tool Runtime 直连业务系统。所有调用都走统一治理通道。
第四，版本边界。工具 schema 变更要有版本控制。不能随意改字段导致模型提示和调用解析失效。
第五，返回边界。工具返回结果要面向模型和用户场景裁剪，不要把内部 DTO、堆栈、数据库字段直接暴露。
第六，责任边界。工具 owner 要明确。某个工具错误返回数据时，要知道由哪个系统、哪个团队维护，而不是变成 AI 平台背锅。
第七，运行边界。工具调用要有超时、限流、熔断、重试和降级。模型可能触发连续调用，不能拖垮核心系统。
7. 常见坑
第一个坑是把 MCP 等同于某个 SDK。真正重要的是工具标准化、上下文标准化和治理标准化，而不是用了哪个库。
第二个坑是把内部 API 原样注册成工具。内部接口命名和参数往往面向系统，不面向模型，模型会选错或填错参数。
第三个坑是工具粒度不合理。太粗会变成万能接口，风险高；太细会让模型难选择。通常按业务意图封装，如“查询保单摘要”而不是“查询保单表所有字段”。
第四个坑是缺少版本管理。工具字段一改，历史 Prompt、评测样本和 Agent 流程都可能失效。
第五个坑是只做注册，不做运行时治理。没有权限、脱敏、审计、限流的工具注册中心，只是一个接口目录。
第六个坑是忽略工具质量评测。工具描述写得不好，模型就会误用。需要用真实问题测试工具选择准确率。
8. 面试追问
面试官可能问：MCP 和 API 网关有什么区别？可以回答：API 网关面向服务调用治理，MCP 思想下的工具层面向模型和 Agent，除了路由鉴权，还强调工具语义描述、上下文、资源访问、返回可解释性和多轮编排。
可能问：为什么不让模型直接调现有接口？回答：现有接口粒度、命名、权限、返回结构都不适合模型，直接暴露会带来安全和稳定性问题。
可能问：工具怎么设计粒度？回答：按业务意图和风险边界设计，查询摘要、查询状态、生成草稿、提交动作分开，不做万能工具。
可能问：如何做工具治理？回答：注册、版本、权限、风险、审计、脱敏、限流、熔断、owner、评测、下线流程都要有。
可能问：如何接遗留系统？回答：通过 Adapter 层封装 REST、RPC、SOAP、数据库代理或页面自动化，对上保持统一工具协议。
9. 推荐回答
推荐回答如下：
我理解 MCP 的核心不是某个具体实现，而是把模型和外部能力之间的连接标准化。我们在项目里参考这个思想，把保单、客户、产品、工单、保全等传统系统封装成统一业务工具。每个工具都有名称、描述、输入输出 schema、权限点、风险等级、结果脱敏策略和 owner。
AI 编排层不会直接调用传统 API，而是先从工具注册中心获取当前用户可见工具，把 schema 提供给模型。模型生成 tool call 后，统一工具运行时负责参数校验、权限校验、风控、执行、脱敏和审计。底层不管是 REST、Dubbo 还是遗留页面自动化，都由 Adapter 层屏蔽。
这样做的好处是 AI 应用和业务系统解耦，新工具可以复用，安全策略也能统一。对企业内部 AI 工程化来说，工具标准化比单个 Agent 写得多聪明更重要。
这个回答能突出架构抽象能力，也能体现你对传统业务系统接入的经验。
10. 延伸学习路线
第一阶段学习 MCP 的基本概念：tools、resources、prompts、clients、servers，以及它为什么适合 Agent 连接外部系统。
第二阶段学习企业 API 治理：API 网关、服务注册、权限体系、审计、限流、熔断、版本管理。MCP 思想落地离不开这些基本功。
第三阶段学习工具设计：如何写模型友好的工具描述，如何设计 JSON schema，如何控制粒度，如何构造工具选择评测集。
第四阶段学习 Java 实现：用 Spring Boot 实现 Tool Registry、Tool Runtime、Adapter SPI、权限校验和脱敏策略。
第五阶段学习 Agent 编排：理解 ReAct、Plan-and-Execute、多工具调用、工具失败恢复和人工确认机制。
最终可以做一个标准化工具平台 Demo：注册三个业务工具、一个知识资源、一个页面自动化工具，让不同 AI 应用通过统一协议调用。这个项目能很好展示 MCP 思想在企业工程中的价值。