想象一下，你的店铺有个超级重要的保险箱钥匙（支付密码）。这把钥匙能打开保险箱（你的收款账户），把钱收进来。现在你想用支付宝、微信支付或者华为支付来收顾客的钱，关键问题来了：

这把“钥匙”（支付密码）到底放哪里？万一丢了或者被偷用了，责任算谁的？

不同平台的做法很不一样，直接关系到你的风险大小！

一、 支付宝：开发者自行决定钥匙放在哪儿

支付宝未直接提供MCPServer的接口，而是提供了MCP的SDK能力，由开发者及第三方平台自行封装对接。

构建思路

华为支付业务在AI时代，积极拥抱面向Agent智能体的开放形态。当前业界存在的MCP协议的能力开放已成为行业事实标准。智能体开放平台也百花齐放的涌现出现。华为支付的能力，内置于华为手机系统之中，优先考虑基于小艺智能体平台做能力开放。

华为支付的开发者对接，涉及端云接口的交互。端侧接口考虑接入小艺的意图框架，云侧接口考虑提供MCP云插件。由商户开发者编排成工作流。将工作流绑定在智能体中，当识别到特性意图时，执行工作流。

先基于华为支付和小艺智能体平台已有的能力，摸索出开发者及用户能做到最优体验，再考虑额外构建补齐的能力。

demo演示构建方案1【华为支付基于存量http接口提供云插件】：

当前业界支付公司提供的MCP支付服务：
银联MCP智能支付服务：https://open.unionpay.com/tjweb/solution/detail?solId=613#nav03
支付宝 支付MCP Server：https://opendocs.alipay.com/open/0go80l
微信支付MCP插件：https://yuanqi.tencent.com/mcp-shop?detailmcpId=683f109ebfbc60d469a9a65a

本文内的代码写法仅表示其基本含义，实际项目中需要做更精确的调整。

1. 基本AOP切面能力

指定切面

在每一个controller类里的接口方法内，对web前台页面传入的参数进行解密

    @Before("execution(public * com.xxx.yyy.controller.*.*(..))")
    public void decrypt(JoinPoint joinPoint) throws CException {
        // 捕获方法参数列表
        List<Object> methodArgs = AspectHelper.getMethodArgs(joinPoint);
        if (methodArgs.size() == 0) {
            return;
        }
        for (Object item : methodArgs) {
            // 对参数项进行敏感字段解密处理
            try {
                argHandlerDecrypt.strategyhandle(item);
            } catch (Exception e) {
                log.error("failed to decrypt, message: ", e);
                throw new CException(ErrorCode.RSA_DECRYPT_FAIL);
            }
        }
    }

技术背景说明：

AI Agent已普遍应用于企业业务的各生产环节，多品类AI Agent应用和开发平台百花齐放。在C端，手机上的AI智能体支持协助用户完成各项简单任务。但在支付环节存在断点。无法帮助用户快速完成支付。

当前市场上暂无协助用户无感支付的AI智能体。三方支付公司也不支持在单个支付指令中，同时传入商户订单和用户授权信息，无法真正的做到无感支付。该专利方案支持ai agent和无感支付相结合，打通支付体验断点。

角色定义与核心职责

技术背景说明：

目前各类钥匙数字化，通过手机设备装载各类钥匙的场景越来越便捷，消费者依赖手机管理各类钥匙。也就衍生出各类数字钥匙授权激活的述求。

以车钥匙为例，车主在线下场景，需要授权给4S店或其他人，目前都只能通过账号输入确认的方式进行。用户操作较为繁琐。通过手机碰一碰的方式，不需要提前输入被授权方的账号及身份信息，更加快捷方便。基于设备维度授权，也更加安全。

技术方案时序图

1.1范围

本文从客观实战出发全面梳理支付一致性相关场景 ，针对不同的场景给出最佳实践，并归纳出通用的一致性设计原则。

本文描述的是支付不同场景下需要保障最终一致性的对象的规则实践，针对一致性保障手段不做细节展开，例如分布式事务技术。

2一致性设计原则

本章节针对一致性设计共性原则进行归纳总结。其中分为三个档：**“严禁”原则是红线原则必须遵守不允许任何例外情况；“必须”原则是相对刚性原则，原则上必须遵守，特殊情况允许例外且特殊情况必须评审备案；“尽可能”**原则是相对柔性原则，引导设计方向正确性，建议尽可能遵守，允许例外但需要明确合理的理由，不强制评审但需要备案。

此前使用个人服务器直接拉取代码仓构建部署。 服务重构后，服务器配置无法支撑完成构建。 尝试通过gitee平台的流水线进行自动构建。

核心就两个步骤：构建打包和上传部署

构建打包：选择NodeJs构建。 需要配置的也较少。选择Node版本号，输入shell构建指令，配置打包后的文件目录。

上传部署：我这里选择的主机部署，需要提前配置主机组和机器。gitee提供了指令可以快捷的添加公网主机。选择上一阶段的打包制品，下载到机器指定路径，然后自定义shell指令完成部署。我这里仅做了解压和移动文件路径的操作。

流水线操作官方指导：https://gitee.com/help/articles/4381#article-header0
从使用体验来说，上手使用非常方便，配置简单。对于个人开发者是个不错的福利。

重构认知：

所谓重构（refactoring） 是这样一个过程： 在不改变代码外在行为的前提下， 对代码做出修改， 以改进程序的内部结构。

存量产品问题：

难以添加新特性：添加1行代码都需要阅读理解相关的几千行代码
存量代码难以理解：培训和维护都异常困难，新员工成长缓慢，某些代码完全依赖于特定的一位老员工，人员依赖风险极大
难以保证产品质量：缺乏有效的自动化测试，添加或修改1行代码都必须手工执行所有的测试用例
接口混乱，组件难以复用：文档缺失、模块内外耦合严重，典型表现为头文件混乱
简单堆砌式实现：各种全局性的控制变量多，并且不断的异常性增加