2025寿险科技创新论坛——会后实录（下午）

感谢各位来宾，我继续深入的给大家阐述一下，借这个机会做每年一度的汇报。刚才孙总已经提到了在广义行业应用软件或者AI原生的新的时代下对于开发人员技能上的新要求，这就让我想到了最近一两年来非常流行的一个话题，就是我们这些程序员未来是否就要被人工智能替代，或者很快就会面临这样的一些危机，我从我们这样一些真实的工作团队的角度来理解这个问题。

 Coding这个概念原来我们认为是专业性非常强的工种或者技能，都需要长期的培训，甚至像算法这一类的能力还是很高端的、精尖的知识体系。大模型诞生，在这个方面表现出来了超出了个人或者绝大部分人的开发能力。这让我想起类比到古代时候所谓的文人士大夫，为什么他们可以成为社会顶层，他们使用文言文、八股文垄断了文化的传播。我们这些程序员某种程度上也是垄断了信息化的进程，所以我们才掌握了一些社会上的资源。

 现在大模型类似于新文化运动一样，打破了这种文化的垄断，它带来的是新生。对于我们这些程序员而言，我们要做的是快速转型和学习、快速拥抱真正对我们有挑战的新的技能，这才是我们需要关注的，而不是只是在这里发愁我们是否要被替代。

 所以回到今天主题上来讲，在这种新的技术演化的过程中，我们要怎么把它以最佳实践来落地到我们行业应用软件开发之中。

 这是基于数据库的应用开发的流程。上面是传统的，就是这几年最主流的RAG模式开发过程，现在很多开源工具，包括大厂的商用化的产品都是基于这个流程实现开发过程，提供相应的工具，提供一些可视化的能力。我们现在实际应用过程中发现了一些问题，虽然目前大模型随着这几年的快速迭代加上开源，已经让我们很容易的应用和体会到AI的一些能力，同时现在的这些开源工具使用门槛越来越低，他的使用难度，因为可视化程度越来越高，集成度越来越高，他的开发难度也是越来越低的。但是我们发现我们作出的真正的应用或者行业端的应用其实并没有达到我们的期望。有两个关键的应用：一、传统的RAG里面的知识库过于单一，它基本上就是基于向量结构的数据结构承载，它的检索也是基于单纯的向量化检索来完成。所以单一性导致它与应用场景是有着相当强的耦合性的，我的调优、我整个开发过程一直是在所谓的切片的方向上在下工夫，一直是在构建切片之间的语义关联下工夫，这个太单一，只是跟具体应用场景相关联。二、我做的数据库没法成为一个企业通用的基础统一的数据库，往往是基于场景来做的。这样一个设计适合这样一个问答体系，但是现在解决的不仅仅是一个对话，这只是第一步，我们要解决的是真正业务场景中一个无感的AI体验，这是要求非常精准，要求流程自动化处理。这个时候我们对于知识的要求要高得多，而且也不能够只是在具体的场景端有一个数据库的能力，而是要在整个应用我们要搭建一个统一的知识库平台。

 这个需要从两个方面来入手，构建我们的最佳实践的体系，一、构建多信源的体系化知识库，进行知识增强。现在这个知识增强本身也是一个行业新兴的技术方向，我们实践比较多，我们不是学到这个技术才这么做的，而是先从应用当中意识到这个问题，去建立了很多实践，然后发现理论体系也在往这个方向上转化，有点异曲同工的效果。这是第一点。二、是在很多RAG的流程里面，形成很多具体的一些实践的总结，要把多信源的知识体系结合RAG开发的工作，结合一些理论界的新的方法才能够形成真正有价值的可以落地的应用，结合这几个重点环节给大家介绍一下我们这两年来的成果。

 首先来看一下知识增强的部分，由单一知识库转化为多信源体系化的知识库体系。这是一个数据库的全貌，我们由一份文档，可能是个制度，可能是个条款，可能是业务的文件，我一个同样条款就要转化成一套体系化的知识结构，它不是单一的基本的文字逻辑关系，而是有着不同的知识结构表达。首先我们的知识要进行文本信息获取之后要逐层进行拆解。一开始是段落信息，要用文档类数据进行管理。我们再细化，对于语句类的信息要拆分成语句的分组，然后以文本知识的方式进行存储，放在类似于ES这种支持全文检索的文本数据库里面。继续细化抽取短语类或者要素类的信息，这类信息会形成序列集，构成序列化的知识，就是一些要素以及要素之间的语义之间的先后逻辑，这是一种序列化知识，存储在专业的序列知识里面。再有一些是高度抽象，我们做了参数化的定义的，我们把他抽取出来放在结构化的信息里面，这是体现出多种数据结构，从关系型到半结构化的，到非结构化的数据存储结构。这是引入多信源。

 第二个方向叫领域知识增强，涉及到领域建模，这是我们的强项，原来很多做AI的公司他们做知识库，他们有一个不足，上午一些大厂也提到了，他们并不了解行业本身，对于行业的这些信息他们能够采集，但是这些信息之间是什么结构关系他们无法去掌握。这个时候涉及到领域的建模问题，就是我抽取出来所有序列，这个序列以语义逻辑来表达，但是语义逻辑并不代表业务实体，我业务逻辑要基于领域关系再重构，这个时候建立的就是图谱，用图数据库存储知识图谱的信息。

 第三个增强叫特性类知识增强，这些采集下来的都是基本信息，我们要进行总结加工和扩展，要生成相关标签，要构建一套特色标签化的知识，才能在应用端跟客户需求，跟客户的话语去相匹配，前面都是专业化的术语，后面这个里面要结合客户的理解，结合大众的知识，要结合标签类的信息再进行构建。

 第四是要做经验类知识的扩展，经验类就是日常业务交互过程中我们已经积累下来的对话，我们要建立出问答对的信息，这个很关键，我们很多知识库其实最终的高效的检索跟精准的检索并不都是来自于这些原始信息的检索，而是由一个问题到一个答案，不是每一次都是陷到里面搜索逻辑关系的，很多都是基于已有的问答对来形成的。原来我们讲模型微调其实由于基于问答对做微调，但是我们没有必要非要这么做，我们可以用知识库来解决。就是问答对知识，因为这个知识最终是会向量化的，他的检索还是基于向量，就是余弦函数原理不变，但是它的内容是问答的数据，这个数据是不断的积累的，所以叫经验类知识增强。有这四个方面的知识增强我们提供的数据库不仅仅是数据结构的差异性，更重要的是它的知识表达的差异性，它的检索方式的差异性。

 有这样一个复杂的知识库体系，一个条款，一份文件，要构建这么多知识库要花多大的工作量，这是大家想到的问题。

 所以我们要有一套数据标注体系帮助大家完成，数据标注有人工和自动化两种方法，我们现在讲到的有相似性的持续批量和不断的新增的这些文件类的信息，我们一定是要采用自动化标注方法。

 现在自动化标注有两种主要思路：一、基于一些标注框架，结合标注模型来经过训练之后实现自动化标注，还有一种是用大模型直接来做标注，两种情况解决的问题不一样，有差异性的。两个都是条款的文件。上面这个就是基于标注模型来做，标注模型一开始我是需要对里面的这些话语、语言表达，要做人工的标注，其实就标注里面的要素，标注短语，标注关键信息，这些信息是基于领域知识去进行总结、归纳出来的要素，这样的一些信息标注完了以后，我们会导入到这些开源的标注的框架里面进行模型训练，把数据导入，然后在这面训练，训练了之后会进行应用，实现自动化标注，然后做人工审核，循环几个轮次提高标准的精准度。我们自己的知识库里面保险条款有大几千款，主要通过自动化标注完成的。现在标注成功率在95%以上，目前限制我们产能的其实不是这个标注工具，是因为我们目前在这个标注环节还是加入了人工审核，为了保证知识库的精准度，保证它的质量，因为人工审核我们还没有完全的抛弃，所以限制了我们批量做自动化标注的产量。

 下面这一块是对语句类的信息标注和提取，这个是用大模型来做的，这个大模型要用提示词来完成，里面会标注我要抽取相应的特征信息，然后批量的就能够从条款的文本里面把刚才我讲的文本类的信息，这种语句类的信息抽取出来。这个现在的质量也是逐渐升高，没有刚才这个模型的精准度那么高，语句应用场景来讲完全可以满足需要。这也得益于从去年底到今年大模型的迭代升级，因为这个技术以前就想到，也有人去尝试，在去年以前这个效果是不高的，从今年尤其从千问的2.5以后的版本，像DeepSeek出来的版本，包括千问3的版本对保险条款理解能力强很多了，他们做语句标注，加上提示词的配合，已经能够有非常高的标注成功率了。这是数据标注的过程，它就是构建体系化数据库自动化执行的重要环节。

 有了这样一套知识库，我这个知识库能发挥什么作用才是最终目标，我目标不是为了做一个数据库，而是要用。多信源的体系化的数据库带来一个好处就是为知识检索提供了多样化、灵活的可组合的检索能力，能够满足我各种差异化的需要，我需要非常精准的信息，哪怕一个定量的信息也可以检索到，我需要一些可扩展的整个规范类的全面内容的综述，我也可以做到，我用不同的知识表达提供对应的信息输出。

 所以现在的理论界对于混合检索，成为了RAG发展的最重要的方向，也是弥补传统RAG能力不同的重要思路，在这个方向大家有很多不同的检索的方法或者检索的一些模型。这是多方面进行了学习实践并进行了验证，我们总结了不同的混合检索模式，用在不同的应用场景下，这四个是分别是：问题分解和多路查询，HYDE这是假设性问题嵌入，图数据库检索，这是与知识图谱相结合，还有一个图向量检索法，这个用在不同场景下带来的效果对于原有RAG有非常大的提升。

 第一，当我们有一些问题，比如说问一些行业的规范，是比较宽泛性的，你需要全面性的给我一个回答的时候，举个例子，我问一个问题，比如说投连保险费用都是什么样的，客户角度就提一个费用，我们怎么理解这个问题？如果我是代理人我帮客户解答这个问题，我就要追问：你是问的期缴保费还是死亡风险保费，还是年度账户类的费分，还是初始费用的扣除？你关注什么？这个时候就要了解客户关注要点是什么，再做精准回答。大模型怎么做这件事？如果我不去做问题的详细分解，就这一个问题不是某一个文档可以回答的，散落在不同文件里面，他可能关注收费方式，可能关注费用计算方式，可能关注的是其他跟别的业务关联的一些问题，我不知道关联什么，我不知道关心什么，这个时候是很难通过一个简单的知识检索把他准确回答下来，所以往往就会出现，要么是答得文不对题，要么就是似是而非，不全面。我们第一步就是问题分解，这个问题分解是要基于领域知识帮他规划好的。有一个问题拆解过程。

 拆解之后我们分成几个子问题，如果他关心费用，这个费用可能是账户类费用，可能是初始扣费，我先分解开，针对每个子问题我再并行多路查询。多路检索完之后形成的内容，相似性问题的解答我再汇总起来交给大模型做最终的输出。这个难度不在于知识库的向量检索，难度是在问题的拆解，这个要依赖于经验库的能力。

 第二个，问到跟产品相关的问答，经常在客户的一些营销场景里面会遇到这样的，这个时候客户可能会问某一类产品，也可能会问某一个产品，这个时候他的检索实际上方向是不同的，我在检索时获取到的要素信息量不同的，当我们可以获得比较明确的检索信息时，我们查询条件比较明确时，就走普通RAG模式去检索和查询就可以了。还有一种，如果给的信息很含糊，我们提炼不到足够多的准确的查询条件的时候，当我的经验库不足以支撑我准确帮他回答，能够有比较明确经验辅助时，怎么办？现在理论方法就叫做假设性文档嵌入，由大模型把这个问题先能够明确化，他答得不一定准，他能把要素信息以他经验先扩充。扩充完了之后我们提取要素信息，再用大模型答的信息去数据库里查，我们RAG是先查数据库，模型输出。它是先由大模型答，再去查，查完之后拿相似性的问题做重排之后再做模型输出。这是文档嵌入的方式。这个用在产品问答上比较有效的。

 第三个，图向量搜索增强，这个不同于知识图谱检索，原来大家接触过知识图谱检索，其实知识图谱检索基于几个关系要素，是能够实现非常精准查询的，但是好处是精准，坏处也是精准，它过于强调你查询要素的全面性和精准定位，但是忽略了语义的关联性，没有模糊的查询方式，所以我们这种查询方法最常见的应用场景就是推荐，还有就是做一些反欺诈，跟图这种关系网络的数据相关的检索方式里面，这是非常新的模式，跟图谱查询区别在哪？一开始问题提了以后，先要由大模型做实体拆解问题里面的关键要素，这个问题要素构建成一个图谱，这个是问题子图，这是第一步。还有另外一步，就是基于这个问题的要素，我去进行图谱查询，他会进行每个要素都会查询多个精准的信息，比如说我做产品推荐，我会查出来一批产品，这是我构建的第二个图叫产品子图，其实就是答案子图，只是我这个场景里面答案就是产品子图。之后有两个子图以后，我要把这两个子图做向量化，就有语义的逻辑关系。之后在这个向量图谱两边的向量化以后，基于向量检索查询这个问题和我的推荐哪一个产品相似度或者匹配度最高。这就是推荐算法的一种新的理论方法，我们在我们做的产品推荐里面已经在用这个方法做实践了，这个检索的子图还会有一个召回排序，有一个推荐顺序，他的精准度，符合客户实际需求的满意程度是最高的。

 我们原来也讲过类似于回答问题或者做一些检索，涉及到算法，都很深奥，现在由于这些工具能力，就是我不一定懂得那么深奥的算法，我同样可以把这些能力应用起来，达到非常好的效果。这个前提还是你得有那套多信源的知识库，才能实现多种类型的混合检索，达到不同场景下更精准的知识查询。

 不管哪种查询，其实还涉及到一个问题就是向量化的过程，知识要通过向量化去存储，我的检索也要通过向量化去做匹配，向量化又成为这里面的一个核心环节，我们在实际应用中我们发现很多时候知识图谱、知识库建立得很完备，我人都能知道这个问题，我去哪可以查询到，为什么有时候就是查询定位得不准呢？我们有一些问题涉及到太专业的术语，这些术语其实向量化模型不懂，它没有学过这些。比如说我们保险有一些术语，我们涉及到的医疗尤其如此，涉及到一些疾病、诊疗方法、药品的名字，有很多其实是不知道的。就是对于向量化模型来讲怎么构建他们之间的语义关系，他也不知道，我们要让向量化模型学会这些东西，对向量模型做一个微调。

 有两种方法：一个是正向的，我要教他新知识，我让他做题，做更多题型，下回你就能套了。所以保险行业术语我们有词根表，我们有基础词根1000多条，整个词条1万多，我们放到训练数据里面，通过医保目录拿到的药品名称、诊疗方法、疾病名称、诊疗的名目都整合到数据中，我们训练它，让他学会这些词汇，知道这些词是专业化的术语，不要把他切断了。

 我们发现这个知识挺好，怎么一检索查的理解歪了，就像做错题，这种叫困难样本，我们要拿出来做人工标注，这样加起来组成训练集，然后用一些微调框架去做一些微调。这个确实达到一些不错的效果，我们认为对于咱们做保险行业，尤其以后要做得更深入，做到一些跟理赔、跟费控、跟风控这样一些环节时，这个过程是必不可少的。

 当有了精准的知识检索之后，有了查询出来的知识，我们不是把查询出来结果直接给客户就行了，我们的目标是要让业务系统变得无感智能化，所以最终要能够形成到应用场景的落地，就要用到提示词。提示词是把我们所有前面的这些成果、知识检索的能力落到应用的关键一环，某种程度上来讲，提示词的能力设计的优劣直接影响到应用效果，对于提示词来讲，大家知道要用提示词框架，现在都叫提示词工程，本身也是工程化的重要的过程。提示词框架有很多，现在多数大家看到都是基于解决问答问题的或者解决生成问题的。我们要解决的就是业务问题，要做业务处理，所以我们自己借鉴了RASCEF框架，它有几部分，前面是指令，指令部分描述的是业务行为，我要怎么做，我要告诉他。第二步就是上下文，就是刚才讲到的知识检索，我检索出来的知识信息要嵌入到上下文，输入这个好理解，就是业务过程中要输入的信息可能是客户信息、保单信息、产品信息、责任信息等等，我用到什么场景就输入。输出就是对输出信息的格式要求，要跟接口对接，涉及到不同的接口标准，这个是有约定的。

 其实这里面最关键的就是指令的部分，对于提示词来讲，上下文是数据库提供的，指令部分就是提示词要约定的，其实在这个里面就是要解决我在业务场景下的准确需求描述问题，我们原来通过代码来实现业务逻辑，现在我是要通过这样一套结构、任务目的、行动要求等等来描述我的需求，这个自然语言不是随便说大白话就行了，也影响效果。这是左总的一篇论文，叫做可操作性管理文件的写作方式，当时他是为了解决在业务软件开发过程中业务的需求到代码实现或者代码设计之间的指导性文档，它能够由传统的业务人员描述的以常规语言的方式提供的业务需求，我们要规范化，有相应的模板来约束，然后生成的可被理解执行的自然语言描述的代码，它能直接转化成代码关系，不是用代码描述的，而是用自然语言描述的。这个文档到了今天有了更加有价值的用武之地，就是用来写提示词的指令。文档由两个大的部分，一个是表单描述记录事实型的信息，还有一类是活动，用5WH的框架约定如何描述一段业务的需求，实际上是需求规格的一种约定方式。这种约定方式在写提示词时提供了非常好的帮助。

 这是一个理赔的报案的环节做赔付初筛的，一个客户报案了之后，我自动帮他判断一下他所报的案件信息跟他的产品责任是否可以覆盖，是否可以提供相关的责任保障，做初筛，现在很多业务都是由理赔人员来判断的，这个可以交给大模型来做。他这有一块的任务要求和操作步骤，这个操作步骤就是业务逻辑，只是换了一种描述方式，就是基于可操作管理文件的方式描述我的业务需求，代表了如何处理这段业务信息。

 我除了要写好这个提示词，过程里面还要做不断的优化：一、精准度优化，要调整描述，让它处理得更准确高效。二、成本优化，之前一直被忽视，要尽可能写得越明确越好，提示词越来越多，导致Token越来越多，成本越来越高，所以还要做的一块就是成本这一块，尤其高并发的应用场景里面，原来高并发的场景没有考虑到Token编写时想的都是如何扩算力，实际上要优化代码，优化代码其实就是优化提示词，我们也举了一些数据。一开始提示词写这么一点，发现精度不高，然后就越来越多，越来越细，越来越明确，提示词写到6000字了，Token都4000多了，看似很美好，但是执行效率很低。所以我们开始做压缩，把提示词拆分，单个是多少，每个的Token是多少，就是问题分解。最后依然保持90%以上的准确率，但是Token数下降非常多的。

 第一个，提示词应用的现实方法，做伤残的匹配，在线报了一个案，涉及到伤残的事故，描述完了之后系统做伤残等级的匹配，对应意外险的匹配，这些都是人来做，选择伤残认定，属于哪一类，匹配到哪个条目，都是人来做，现在交给大模型来做。以前我们想，你把这段内容给我了，我有伤残等级的评定标准，然后我就匹配，文字匹配，行吗？完全不行。后来就说大模型不行嘛，理解不到位。其实当下大模型不是AGI未来全能的大模型，我们现在要做的是把处理内容要尽可能的明确化，让他具备在这一单一的相对简单的问题下能够实现自我的判断能力，这就够了。当实现这一点的时候可以通过现有的行业经验，对业务系统的组合能力，我可以逐渐的由一个问题去解决变成多个问题配合下来，最终解决这个问题就行了，就是多个提示词逐层拆解问题的重要实现效果。第一步先判断伤残的提供和保险责任匹配不匹配，是否在赔付范围内，就是伤残的判定。之后获取伤残涉及到的部位，髖关节等等。还有伤残的状况进行类别的匹配，最后一步匹配出具体的条目，这里涉及到关键环节，要把人身保险身残赔付标准做了图谱的知识构建，没有多信源的知识库这个还是实现不了。所以这种知识库加上合理的分解我的问题和匹配适合的提示词，我这样一个理赔的业务环节就可以实现了，实际上理赔涉及到很多类似的问题，很多类似需要专业人员的判别，原来我们都认为大模型是做不到的，其实并不完全做不到，主要没让大模型把问题明确、细化，当你足够细化，足够可以基于明确的知识库去匹配的时候它就能做到，当然不是简单的一步，他要通过多步来完成。现在在我们系统里面实现了，我们还在继续做，理赔场景多了，我们也是一个一个的逐步找理赔方法。

 再举一个例子，我们保险产品出来条款以后要报备到保监会，他有一套合规规范，不符合规范是会被打回的，这是我们从当年保监会到现在金融监管总局曾经出台过非常多的条文制度去约束要求我的保险产品的描述，历史已经很长了，20年了，它都有哪些规则他们也说不清，我这个条款到底是否完全满足规范，都是凭人的经验来判断，这个准确度不高。这个给我们用大模型解决问题一个非常好的机会，我们整理了历年所有规则，目前发现76个监管文件跟条款的合规性相关，我们把他里面每个条目拆解下来，形成1000多个规则，这个后面执行的。关于它的制度问答信息构建了2300多个问答对，这个主要是做知识库的回复和后面提示信息展示用的，这里有例子可以展示来看。

 校验过程是1000多个合规规则，不一定每个条款都能用到，某一类的条款平均下来是200多个规则，我们对规则做了分类，你要满足什么样的要求，有的是错误事例，你不要出现像它这样的内容，我们都做了规则分类和拆解，这些文字都是序列、短语类的文字，还有一部分是文本类的文字，我们放到知识库里面，可以便于提取的。

 规则分了几类，段落类、文本类、短语类等等，用大模型来检验。它的检查你也不能把规则分解了之后直接给他一个条款你就读它也不行，准确度不高的，要把条款要分解，就是每个条款要用数据标注的这套过程，依然要构建一套知识库，包括段落类的信息、语句类信息、短语类的信息，针对段落类的用段落类的规则校验，是逐步一一对应做的，只有这样才能做到完备、准确的校验，这是可用的，大家有兴趣的话可以试用，你们可以给我们一些条款，我们帮你们做个校验，现阶段我们也不收什么费，帮我们验证一下。

 这个也是非常复杂的提示词的应用，这个提示词就一个框架，但是里面要嵌入的内容，就是上下文的部分和指令的这部分，上下文部分是这些知识注入，指令部分是规则部分的嵌入，来构成我的一个提示词，最终完成校验，我写了一个提示词，但是实际执行过程中每个条款大概有200多。

 提示词工程，既然是工程，跟软件开发非常相似的，这个在很多开发工具和平台里面比较缺失的，提示词只是提供了编写的可视化，没有像代码一样做工程化的管理，提示词也是有生命周期的，所以我们在很多工具平台上提供了一套管理的工具来做辅助，比如说编写过程中的可视化的展现去做对比，我去调试时验证，哪个版本效果最精准，用这个提示词调用哪个大模型效果最好，还提供了动态评估，提供了测试验证集，这是基于经验数据总结出来的，也是问答对的，进行提示词的回归测试，就是调整完了以后也会测。还有就是版本管理，提示词也是需要有版本的。

 关于我们的整个应用过程中能力大家都已经看到了，逐步通过知识库的构建，通过检索的优化，通过提示词的建立，可以满足需要。但是有一个重要问题就是要强调更加优化的低成本与高精度，所以这里面也在这个部分就是现阶段的尝试过程了，在做模型的蒸馏，为什么做这个？我们现在发现很多应用场景，其实我对它的要求很明确或者单一的，不需要什么都能干的模型，我也不需要他有多少强的思维处理能力，就需要阅读理解能力足够强，因为我已经把你需要做的事情非常明确化了，这种确定性要求更需要你高精度、高效率的处理能力就行了。我们尝试用蒸馏方式压缩一个小而且专而且精的小模型，进一步的提升我的投资利用率、回报率，降低成本。比如说做一些会议摘要场景里面，一些客服对话的质监，在这些场景里面比较适用，因为我对他的需要是比较单一的，可以提供低成本、高效率的解决方案。

 做意图识别，在有些场景下我对他的要求比较明确的，我知道我对他的路径分类比较明确的，我做意图识别就是解决几个具体问题，就是需要很小尺度的模型就可以了。这个就适合做蒸馏。

 蒸馏过程就是用一个教师模型生成专业场景下的训练数据，然后教会小尺度的模型学会做专业的活。现在有一些开源框架可以实现蒸馏的应用，我们现在基于Distillkit工具做了一些，效果还可以。保险公司的销售部门在开销售经营分析例会里面要做一些重要信息的摘要和质检，他的场景要求很明确，而且就基于销售业务，只是里面要素信息结合企业自身的信息。我们选择了DeepSeek-R1，小模型选择千问2.5的7B，基于刚才的场景生成1000多条训练数据，然后去做小模型的蒸馏。一开始效果也在不断的优化。现在逐步让他效果已经达到了一个小模型和一个大模型能力相近的程度，这是我们对它的的考核指标，现在常规情况下通过前面的一些方案已经让大尺度的模型具备了实用化的，解决实际业务需要的功能，已经实现了，现在我需要一个小模型，一开始的小模型是不行的，我现在怎么办？就是通过蒸馏以后基本上可以让7B小模型在这件事上达到跟大模型同样的能力水平。蒸馏本身有框架去做，这个事跑起来不难，主要是训练数据问题，还是要有人工标注的过程，开始人工标，后面自动标，提高训练数据精准度，这是它的核心。我们开始拿一些样本，都是会议记录，由语音转成文字了，通过人工，再通过自动工具，标注出相应的特征信息，因为我要拿一些样本，因为我找的信息是类似的，但是每次说出来的话不同，我要知道每次不同表达方式是关于产品的，还是销售业绩的，还是其他的，关于什么的我要标注出来，让后面自动识别判断。这个开始过程我是积累了一些标注模型抽取了这个数据，用这个数据去形成提示词，交给教师模型，他用这些提示词来去生成训练数据，训练数据出来了之后我们再进行一次标注的环节，这个环节很重要，这个环节也引入了人工审核，包括专家审核、自动评估两个手段去做。二次标注之后我们才串联起了整个过程，中间加入了一次标注。这个过程做了几次，不断的去优化我们生成的训练数据，所以像我刚才说的达到最终大模型相近的能力效果是经过了好几次的训练效果，其次每一次主要是优化训练数据。

 总结一点，大家可以看到，现在行业里面最火的像大模型，一些工具平台，包括甚至一些算力，是AI领域大家最关注，资本投入最多的这些场景，但是真正到了我们这些行业应用端实际上真正起到重要作用的并不是这些工具，也不是开源的模型自身的能力，往往是这些行业的数据、这些领域的知识和模型，甚至一些传统的可操作性文档这一类的工程化的方法才真正让模型能力、开发工具能力落到实际应用场景里，而且这些场景是能够跟我现有的业务融合的，而不是做了外挂，不是做了小助手，只能点出来它能给我一些知识辅助提示，不是这样的效果，而是我们系统具备自主决策的能力，这是我们的目标。

 我们在做广义行业应用，是要落到业务系统里面，让它具备自主决策的能力，这样体现智能化的应用，这些里面都要结合我们真正的对行业的了解、业务逻辑的了解、数据模型的了解。最后一句话总结：ISV是实现AI推动业务创新和变革的核心力量。

深圳计算科学研究院&崖山科技全国金融业务总经理 郭凯明

在寿险行业加速构建自主可控、安全高效数字基础设施的当下，深圳计算科学研究院 & 崖山科技全国金融业务总经理郭凯明受邀出席中科软寿险科技创新论坛 2025，围绕金融关键业务系统规模化替代的技术路径与解决方案展开深度分享，以下为演讲实录。

从试探到深耕：我经历的金融信创五年之变

再次来到古北水镇，让我想起了5年前，当时也是中科软搭建的平台让我们有机会交流探讨。2020年的保险科技创新论坛上，当时信创刚刚开始，很多客户关心的问题是在：数据库的信创怎么做，大家都知道数据库是金融行业当中信创工作中最为高精尖的关键一环。那时，客户对数据库的信创满是疑问：要不要先从边缘系统试起，核心系统别想了，再观望观望？分布式数据库也是有一定优势的，但很少有人用过，而且开发改造量大、运维复杂，小公司能驾驭吗？更有不少人期待："要是有一款集中式数据库，能同时满足性能需求并实现Oracle平滑替代就好了"。

在中国，Oracle有很多相关从业者和上下游从业者，换句话说就是有大量的粉丝，据说在中国有30万与Oracle数据库相关的从业人员，所以如果能简单平替Oracle那信创就再简单不过了。五年前我在一家分布式数据库厂商工作，当时正在推广分布式数据库这个概念，记得2020年在大会第三天的爬司马台长城的时候与很多寿险的客户在一起辩论，我说分布式才是未来，分布式更好，很多客户说分布式太重了，分布式改造量太大，我们小小的寿险公司没有那么多人员改造这些东西和处理运维复杂度的难题，会分布式系统的人也很少，当时我们没有人精通。现在回忆起来，这是当时客户们关心的四个问题。

五年过去了，来到了2025年的今天，金融信创已全面进入深水区。赛迪顾问数据显示，金融行业的信创从边缘系统试探，逐步迈向核心系统规模化替代阶段。这意味着，数据库产品不能再只是满足"试点可用"，而要经得起核心业务的严苛考验。

过去一年，我走访了全国几百家大大小小的金融客户，发现客户们的关注点已从"要不要做信创"转向"如何做好信创"，核心聚焦了四个问题：

l 核心系统替换难题。核心系统是生命线，关联上下游开发商与关键业务链路，牵一发而动全身，选什么数据库、怎么替，成了头等大事。

l 信创品牌收敛困惑。试错阶段，不少客户引入了10家甚至更多品牌的数据库，如今想从10家精简到2-4家，来降低学习与运维成本，但市面上几百家国产数据库各有优劣，难寻"六边形战士"。

l 分布式数据库的适用性争议。"真的需要把所有业务都放在分布式数据库上吗？"这是很多客户的疑问。分布式虽有优势，但并非万能，中国人有句俗话“不要把全部鸡蛋放在一个篮子里。”

l 成本与自主可控压力。随着科技预算缩减、人力短缺、厂商绑定风险（比如被迫替换全平台硬件但用户却缺乏议价权）、降本增效诉求，层层压力倒逼数据库选择更趋向理性。

所以回到今天，核心系统与规模化替代的信创工作，对数据库产品提出了全方位考验，客户的数据库信创四大挑战尤为突出：

l 迁移与兼容性成本高。寿险数据需长期保存，不少系统老旧，涉及Oracle版本更为早期、更为复杂，PL/SQL存储过程、自定义函数等高级特性，迁移不仅是技术问题，更可能引发业务改造，成本陡增。

l 性能瓶颈显著。部分国产数据库内核能力不足，复杂查询性能下降、TP场景延迟抖动，难以支撑高并发业务；而分布式架构虽被寄望突破性能，却带来新问题。

l 架构复杂度陡增。分布式需解决数据分片、路由等问题，业务改造与咨询成本高；同时，系统拆分可能导致"1+1<1"的性能损耗，反而降低效率。

l TCO居高不下。硬件投入、改造人力、运维隐形成本（比如分布式系统的"运维噩梦"），让不少客户感叹"信创投入远超预期"。

YashanDB：全自研基因+共享集群，破解保险行业痛点

深圳计算科学研究院由樊文飞院士领衔，是深圳市重点打造的“十大基础研究机构”之一。YashanDB是深圳计算科学研究院重点自主设计研发的新型数据库系统，为客户提供一站式的企业级融合数据管理解决方案。其团队原创的有界计算、增量计算等理论，为YashanDB奠定了坚实基础。

YashanDB的发展历经三个阶段：2013-2018年理论奠基，2019-2022年工程落地（获"数字中国建设峰会十大硬核科技"），2023年起进入市场化与核心替代阶段，去年发布的V23版本，真正突破共享集群技术，实现与国外主流数据库的1:1平替。

目前，深算院500+团队中研发占比超90%，发表高水平论文121篇（CCF A类109篇），100%自主研发崖山数据库、采石矶数据质量、钓鱼城数据分析三大产品，从内核到工具均实现了自主掌控。

在我看来，做数据库研发不能是一个草台班子，如果说做一个网站或者做一个简单的APP应用，很多搞开发的人攒一个Team，很快就能开发七七八八。但是数据库不行，因为数据库内核太复杂了，需要强大的工程化能力。YashanDB 自创立以来，其核心研发团队的长期投入形成了卓越工程化能力，塑造了金融核心数据库替代的利器。通过共享集群技术突破 “塔尖” 难题；采用多写无锁并行引擎、页内锁技术、全局细粒度并发控制等核心技术，实现单库多实例集群的真正多写，应用透明且全局缓存强一致访问。全国产环境下，YashanDB共享集群TPCC测试性能已经达到非国产环境下国际主流数据库的同等水平，并基于此为核心业务提供“三个不变、两个对等、一个更优”的1:1规模化替代方案，助力企业基础设施成本节省超 50%，服务器数量减少 2 倍以上，在架构不变的前提下可以实现性能与扩展性双重优势。

作为深圳计算科学研究院的主营业务，YashanDB始终专注于数据库领域，拒绝将数据库作为撬动其他软硬件销售的工具。相较分布式数据库，YashanDB提供更理性的共享集群解决方案：多数场景下，主备共享集群的高可用方案已能满足需求，同时可避免分布式架构带来的数据拆分复杂、网络通信瓶颈、分布式事务性能损耗等问题。通过简化架构，降低系统复杂性与管理成本，减少 DBA 人力投入，同时保障业务稳定性，真正实现 “省、稳” 的规模化替代价值，彰显实事求是的技术态度。

YashanDB 秉持 “把方便留给用户，把复杂留给自己” 的理念，通过 “三个不变” 降低替换门槛。在应用层面，高度兼容 Oracle 语法、语义及 PL/SQL 高级包，迁移平均仅需 4-6 周，多数用户实践中能实现应用代码零修改；运维能力对等，兼容 AWR、RMAN 等常用工具，有利于DBA复用原有技能实施运维；架构层面，采用高性能共享集群，无需重构即可平滑过渡。某头部城商行的客户关系管理系统选择YashanDB替换传统数据库，其4000+个SQL和对象、9.3万行存储过程，仅3周完成平滑迁移。

最后，YashanDB 在安全、稳定与成本控制上表现突出，综合 TCO 较传统方案降低 3-6 倍。安全方面，内核代码全自研，通过商密、等保认证及 EAL4 + 等权威认证，构建多层次防护体系，确保数据零泄露。稳定层面，支持两地三中心架构，实现业务零中断、数据零丢失，RTO<10s、RPO=0，满足金融级高可用要求。成本优化上，硬件投入、运行能耗显著降低，其全栈自研特性确保每个字节可追溯，为用户提供安全、高效且经济的数据库解决方案。某头部证券选择YashanDB替换Oracle数据库作为其核心业务资产估值系统的数据底座，最终实现性能提升超过20倍，成本节省超过60%。

最后我给大家介绍一个崖山科技的实践案例，YashanDB在2023年推向市场之后，我们在各行各业取得了不少案例，例如金融行业的人民银行数字货币研究所、华润银行等等，此外，目前我们有很多案例都在孵化过程当中，以PPT中所呈现的某城商行核心清算系统为例，该系统目前已成功上线YashanDB，客户从一开始的疑虑到现在的稳定运行我感触颇多，在这个过程中，借助崖山共享集群，将生产系统与Oracle做了并跑，并跑六个月始终数据稳定，最终客户信任并把后背交给我们完成上线。

最近深圳计算科学研究院过六周岁生日时，樊院士说：创业六年，我们用负重前行的实际行动兑现了无愧于心的初心使命，我们用日复一日的付出和坚守，让科技报国的理想照进现实，相信YashanDB必将在中国乃至世界的基础软件浪潮中站稳脚跟，绽放价值！

再次感谢各位领导的聆听，希望大家关注我们，谢谢大家的支持。

中国人民人寿保险信息科技部部门总经理 何东川

何东川：各位领导同事大家下午好，感谢中科软提供这个场合跟大家做一个交流，我们感觉保险行业大模型应用处在同一个水平，目前也看不到大模型可以带来投产比的改善，但是我们看到这个是一个非常强的趋势，要全力拥抱大模型，怎么推动业务高质量发展。人保集团也是积极拥抱，取得一些积极成效，我们也想借这个场合跟大家做一个交流。

 介绍一下人保寿险，是在2005年设立的，今年正好也是20周年，我们也是有一个全国性的保险公司，也覆盖了所有省份。

 人保寿险从2023年开始做大模型的探索研究，对大模型的认识也是感觉到从人工智能起步之后，现在真正是进入了大模型时代，从原来大语言模型，可能会进入到新的多模态的发展。从对话、文本交互、图象识别、视频的生成等等。这样一个技术推动也会给各行各业带来一些新的模式。

 我们看到一组数据，真正智慧涌现还是来自于整个参数的大的变化，我们这里拿了一张图，其实从人工智能的发展过程中来看，真正的智慧涌现应该是在ChatGPT、OpenAI达到百亿级参数时才能真正体现深层次的对语言的理解。

 大模型大家都很清楚主要就是两个通用模型在往前推进，一个是快思，一个是慢想，应用在不同的场景，现在我们在不同的领域也在用这个场景来推动，包括在通用里面主要是用一些决策的模型，我们都会用快思模型推动。比如说进行意图的识别、客服的场景、实时的交互，推理环节。特别DeepSeek环节，推理这个场景也在内部做一个使用，这个对我们内部人员学习起到很好的作用，把它整个过程、条款解读、保险建议书和比较实用的专业场景，这个对内部人员也是很好的机会，在里面推动了整个条款智能的展示，这两个场景在内部都在进行一些大规模的应用。

 其实从我们最早叫知行合一开始，现在进入到问行合一的时代，我们看到提示词的工程也好，问问题跟你最终能得到答案这是非常强相关的关系。所以问行合一也是未来在整个企业发展过程中都要推动的，我们也要普及对大模型问的能力，我们一直在推动提示词工程的培训，这样才能推动大模型的发展。

 AI发展来看大部分企业包括内部也是在初级阶段，都是部分取代，我们从2023年开始上线了一些大模型应用，但是客观来讲还是在一些部分组件的取代，比如说某个大的业务环节里面增加一点的大模型能力的解释。从大模型真正对企业产生颠覆性影响或者推动力的话，应该是在整个大的业务环节里面的取代，就是大模型真正取得成效的话，应该取代某些系统或者整个大的业务流程，才能体现大模型的能力。这是在大模型推动过程中逐步推动的，从开始对部分组件的替代，在这个大的流程里面增加AI的组件，最后会取代相应的系统，这样才能真正推动大模型在整个企业的应用。同时可以产生原生的能力，会把大模型的能力体现在所有企业的功能组件里面推动。

 大模型不是锦上添花的作用，很多人习惯性的是大模型做一些小的应用、小的工具，其实真正深入企业里面会成为企业非常重要的应用工具，成为企业里面处理任何业务问题、提升业务效率以及带来客户体验的重要工具和思路，这是对大模型的认识。

 我们也在思考说企业怎么真正把AI用起来，其实每个企业的每个环节都值得用大模型重新做一遍，我们做一遍的背后就是你的问题、你还存在哪些问题需要解决，这个是我们讲这个问题层面。另外是对这个问题的解决有没有相应数据做支撑，提升决策能力，有决策能力之后，这个领域人是否就能做好，如果人做不好才是用大模型或者用人工智能更好的推动，这是我们在大模型领域非常粗浅的认识。

 下面简单介绍一下人保在大模型的创新应用，人保大模型是在2023年开始在推动，在2023年荣获了金融电子化的金融十大事件，大模型有一个试点，实际上金融行业我们是第一家，这是金融总局刚刚批的，我们到七八月份正式上线，我们在这个布局里面包括算力也好，包括整个技术团队，我们也是遵循六个统一、五位一体往前推动。

 寿险是依托集团的能力，把集团大模型的能力和人保的支持应用到寿险里面这个垂直领域里面做推动，在这个过程中也重新构建了自有的大模型场景，主要应用在知识问答、专业领域。

 在今年DeepSeek出来之后，我们也重新围绕着DeepSeek这样一个工具又重新对DeepSeek应用的场景做了全新的布局，我们很强调规划引领作用，因为算力总是有限的，不可能把所有场景都用大模型做一遍，还是要聚焦，在这个过程中最重要是要把项目拎出来，这些项目的见效、使用人群是值得的，我们才会投入推动。

 我们自己搭建了一套AI应用中台，用开源的工具，整个各种能力的集成，我们开放给内部各个项目组，比如说在核保的环节，我们核保项目组可以做一些辅助功能，我们核保人员可以在问答里面，整个基座以及能力都是由大模型项目组做一些提供的。

 同时在这个过程中，上午也谈到了这个应用，DeepSeek出来之后我们做了全系统的问卷搜索，我们搜集到非常多的需求，各个部门和分公司提了很多大模型的需求。其实在这个需求收集过程中我们做了梳理，大家提的一些需求和问题小模型可以解决，不需要到大模型层面。所以这个过程中一定是大模型和小模型的应用。

 在大模型应用过程中意识的唤醒以及全员应用非常关键的，2023年我们推动过程中把大模型能力形成品牌AI保宝，所有大模型的能力以及对外输出统一都是用AI保宝这个品牌对外提供。我们在AI保宝上面临的客群，金融监管总局不能面客之前我们主要针对内勤和营销员，支持的场景主要是在办公类和坐席类、产品类做一些支持，当然随着总局对面客这一块的开放，我们未来也会逐步推动面客的相应的场景推出。

 目前我们介绍一下在AI保宝里面提供的能力。

 首先就是办公助手，我们用得最多的就是贺报，一年大概有几十万张贺报，可能营销员做了一个大单就需要去发，都是用大模型生成的。另外一个就是百问百答场景，我们公司有很多规章制度，比如说人事制度、财务制度，我们综合部门频繁接到基层公司的电话提问等等，我们都把它输入大模型之后，这个大幅度减轻了这些部门的工作量，这些部门都会主动跟基层讲，你们先别问我们，你们先问大模型，如果不行再来问我。其实准确率我们经过了一些提升和内部投喂的蒸馏提升，我们内部正确率达到94%，在百问百答环节还是起到了对公司的内部效率提升的关键作用。

 第二是坐席助手，包括客户的问题，包括内部的坐席可能限于知识的限制，需要各种搜索，我们怎么把客户这个领域问题进行一个输出，另外一个就是客服代表，我们一些企微的运营人员，这一块都需要我们相应的一些辅助的东西，甚至包括核保，理赔，这个都需要专业知识的推动。目前也在逐步过程中通过数据库的投喂、资料投喂，实现对相应的岗位人员的专业性的提升。

 第三就是百问百答，把公司所有规章制度进行了投喂，这个调阅量还是可以的，一年达到几十万次，整个准确率也是有很好的提升。我们在这个过程中最大的难点应该是投喂的规章制度的梳理。我们之前把人力部所有历史规章制度梳理出来之后，我们发现里面写的很多规章制度相互冲突的，这个是通过大模型这样一个投喂之后反而影响相关的业务部门要去修改或者更加精细化他的制度发布。

 产品宝典，这个也是非常实用的功能，因为寿险产品比较多的，而且有个行业性的特点，比如说像去年我们在利率下调时，产品都要换一拨，寿险产品开门红也好，都要推出一些产品，原来停售的搀进都需要有全景的展示，停售产品可能今年刚停售，但是客户买了，以后他有一些问题也要做一些支持。所以在这个产品宝典里面把全量的产品，包括停售也好，之前发布的产品，所有条款和相关的内容，包括一些理赔和核保政策都做了输入，实现了全量产品的有效查询。

 其实大模型很多能力也需要用到内部，特别是科技条线内部的编程、测试，我们在主动拥抱，也实现生产率的大幅度提升。我们也在积极推动。

 在数据领域，这个也是比较重要的场景，我们实际上看到每年在数据报表上的投入非常大，但是像领导不太满意，因为他的管理思路经常会变，我们能不能实现领导通过问答形式就能获取所有的数据报表，今天我想要相应的某个省的业务情况，他能调出来，而不是通过运维或者提速方式来解决。我们想实现，领导开会时不需要PPT，只需要对着大屏幕进行问答，所有数据都能出来，真正达到大模型的效果。

 中后台的智能审计，像人行对反洗钱要求比较高，像有没有按照人行的标准要求去做，原来靠手工操作，现在靠大模型的能力，是可以解决我们在反洗钱、合规、风控的各种要求，这个也得到了内部部门非常大的认可。

 还有营销环节，包括计划书，其实我也看到中科软跟腾讯有一个智能陪练的计划书。原来我们都是通过系统的方式实现功能，其实未来我也感觉到是应该通过语言交互的模式通过大模型实现计划书的制定以及实时修改。

 以上是人保寿险的探索，也是跟大家走在同样的水平线上，大家都在摸索的过程中，实际上我们也没有看到大模型真正给企业带来质的变化，其实这个已经到来，只是需要一定时间，希望跟大家一起探讨推动大模型的应用，真正通过技术力量推动业务的高质量发展，谢谢大家！

大家保险集团科技总经理 郝晓波

为了敏捷支持我们的业务发展，在业务变化时快速调整我们的IT系统，我们很多企业的科技建设中都研发了企业中台,就是对各类业务系统的原子功能进行API化封装，并做编目，其中包括自适应的元数据描述，自动的SDK生成、自动化的测试、甚至统一的权限管理、部署运行、性能管理等。中台让我们能快速在组建业务流程、快速适应业务变化。

 现在到了新的AI时代，中台建设是否有一些新的方法论？有没有一些新的技术策略与工具？最近我们也有一些思考和探索的成果，这正是我今天想和大家一起探索的话题。

要回答上面的问题，就要先回答几个问题：一，AI的核心能力是什么？二，企业数字化平台的发展趋势是什么？然后我们才能知道，AI的核心能力能为企业数字化平台的发展做到什么。

我们先讨论第一个问题：AI的核心能力是什么。

大家现在用AIGC,也就是“生成式Ai”来称呼现在的大模型。说它是“生成式”AI，我是反对这个说法的。其实大模型AI的关键能力不是生成，生成内容只是它能力的表象。为了生成我们能接受、质量良好的内容，其底层支持是知识、常识、逻辑，甚至符合人类的观念的价值观，这其实是AI最核心的东西。也就是说，AI不只是一个内容生成的工具，它是认知工具，

认知是什么？一、检查分析信息，二、作出判断和决定，三，制定执行方法，四、付诸实施。但现在AI不能直接做到执行，所以我先对实施这一条划个删除线。

认知能力把计算机从规则机器升级为认识机器。能用新的方法解决问题，也能解决我们之前用规则编程的方式很难解决的非线性问题，这个是我们数字化建设的新的范式。

另外一个问题是，我们企业数字化平台的发展趋势是什么？

数字化平台的发展要紧跟、甚至引领企业转型趋势：工业化时代，企业的主要问题是解决生产问题，做出什么产品客户就买什么；工业化成熟之后技术升级，生产能力加强，可以满足不同需求了，于是转了需求导向；到互联网时代，信息技术让我们有能力根据客户的个性的要求来去灵活适配不同的产品、营销策略等，于是成为客户导向市场。

那么到AI时代，企业的诉求是什么？

我想不管AI时代会是什么样子，我们可以总结出一个趋势来，就是技术让客户的权利越来越大，技术也让我们企业的应变能力越来越高，这也是前些年“数字化转型”这一课题的主要任务。

在AI时代，是否可以继续推演，把这些变化趋势推向极致？

我们之前说业务需要快速创新，未来在AI时代，有没有可能让AI去主动创新，甚至不需要人类的参与？还有组织效率，在AI时代有没有可能通过AI与AI的沟通，实现真正理性、高效的沟通，消除人类带来的不理性的环节？有没有可能用Ai来实现快速高质量的科技实施能力？

个人认为，AI认知能力正是可以做到这些的东西。把两者结合起来可以看到，我们企业的数字化转型，现在可能要准备进入AI化转型时代，最终愿景将会是一个AI自治型的企业，我们所有业务不再通过人，而是给AI最大的效率支持，让AI自主决定如何执行我们的业务，包括AI和客户的交互、AI的决策和执行等等。这是未来可能的一个最终目标。

如果基于这个目标，我们的数字化中台应该怎么规划呢？

在大模型AI技术出现之后，我们很多企业在前台和中台之间，加了一个AI中台，其中用AI Agent技术来响应各个业务领域的智能化任务，比如说管理领域、运营、销售、服务等，这些Agent和前台程序进行交互，甚至直接与用户对话，把用户需求让AI来处理判断，然后在Agent里面编排或是编码对应的业务逻辑，实现用户价值。

 AI Agent形成了AI中枢层，一定程度上可以让AI决定后续的业务逻辑，但是还是有痛点的：当我们在做Agent的时候，不得不人工编排后续逻辑，或是用代码的方法组织业务处理。而且因为这个程序是人编的，要求人要理解业务需求，去学习现在中台的API文档，把程序编出来；程序运行时遇到意外的问题时也没法处理；而有一些新的基础业务规则变化时，我们程序也没有办法自适应来去应对这些新的变化。

在认知型AI的条件下，这些问题能不能解决呢？我找到了一个答案，就是“MCP”。

MCP他是Anthropic公司发明的“模型上下文协议”。人们为了让AI能执行任务，做了很多执行器程序，这些程序有很多不同的写法，很多不同的实现方法，这让AI在使用这这些执行器时遇到困难。

而MCP协议规定，每个执行器要以标准化的方法（JSON）向AI介绍自己，描述自己在哪里，能提供什么功能，参数是什么样的，走什么网络协议。这样AI就可以在在合适的时候来调用这些“自我介绍”过的工具，从而实现业务功能。这就是MCP协议作用。

MCP的关键点在于MCP工具是自注册的，它向AI自己汇报说我有什么功能，这是很重要的一点，这形成了执行器工具的元数据集。

自从MCP这个东西出来之后，很多厂商立即开始支持，包括上午腾讯的产品中介绍的Agent全面支持MCP。现在MCP已经是万物可以MCP了，有网络搜索、读写、云盘、执行操作系统命令，打包软件、发布……用MCP调用Blender软件做3D建模都可以，最近微信甚至把生成支付码的功能也MCP化了，让AI可以向用户收费。

右面是几个MCP的市场，阿里的MCP市场，腾讯的，第三个是字节代码编辑器IDE……现在无论什么东西大家都在想着要把它MCP化。

那么我们业务中台里的API是否也可以MCP化？当然可以。只要把业务功能，那些保全、理赔、那些功能MCP化之后，AI可以调用它。

有了MCP功能之后，让我们把数字化中台再增强一下，原来AI中枢各种Agent已经升级成MCP Host。而对于我们的中台API，增加一个MCP的包装层，让它从原来REST、WEB Service或是其它什么协议的方式，转变成符合MCP标准的格式，就完成了中台的MCP化。通过这样的包装，我们的中台就可以直接被AI调用了。

如果现在中台的服务都已经是MCP服务，那么这些AI Agent就可以利用自己的认知能力，动态决定如何实现业务操作。比如用户要提交一个保全申请，我应该调用哪几个中台的MCP的工具？AI会产生一个执行计划，先查一查用户的身份，把保单号放到提交申请的API参数调用它，然后生成批单……

在这种情况下，已经不需要在Agent里面编排后台执行逻辑了，因为AI可以把这些东西全部简化掉。

如何实现中台的MCP化呢？

一、我们把自己业务领域分类，比如说用户管理、订单管理、库存管理，各种做个分类，决定哪些是比较安全一点的，可以尝试的优先做MCP化。

第二，根据业务角色对MCP服务做权限管理，因为MCP协议本身是社区里面正在蓬勃发展的协议，它还不是特别完整，所以有些细颗粒度的权限管理还需要我们自己处理。

第三，在现有API的MCP化这一步上，可以用OpenAI的这些描述文档直接来实现MCP定义的，这个代价是不高的，而且已经取得了很大进展。

第四步，MCP Host如何根据AI的反馈调用对应MCP工具，这个实际上我们不需要做很多，因为现在Agent、各家AI的SDK里面都开始支持MCP，我们不需要做很多的工作了。

通过这种方式实际上我们把中台完全就给MCP化了，让AI可以自由调用，让AI决定业务流程是什么样的。

让我们考虑一个MCP的生态设计。其实一切做AI平台、有交互入口的厂商都可以思考MCP工具的市场化，比如AI浏览器、桌面助手、随身Ai终端等。它们与用户交互，跟用户对话，认识用户，记录与管理用户信息。在与用户交互的过程中，对于发现的用户需求、命令等，比如定餐或者定车，如果有对应的MCP的服务已经被注册的话，这些服务就可以被AI自动调用的。

用AI平台来去统一做用户入口，MCP的工具则由其它开发者、服务商实现功能，因为服务价值的场景无穷无尽，不可能让单个平台方来实现，可以做为价值实现的一端，用市场动力激励服务者参与生态。

而入口端的各种AI平台和大模型服务本身应该尽量免费，降低门槛，而且大模型的能力也会越来越趋同化。

让我们设想一个真正的应用场景：比如说我们有养老社区、居家养老等服务。我们为我们的客户，也就是居住的老人们，配置AI音箱，养老机构、服务机构可以把自己定餐服务、定车服务等实际服务注册在这个音箱的MCP市场当中。这些老人日常与AI音箱聊天的过程中，AI已经收集了用户的很多信息，比如他喜欢的食物、他昨天的菜单、他的慢病与医嘱用药等。当老人说：“你可以给我定个餐吗？”AI音箱就可能回答：“好啊，我建议你今天来点低热量的，比如上周那家轻食鸡肉杂粮饭，你当时说很喜欢的。”老人说“可以啊，那谢谢你！”AI就可以调用养老院提供的MCP API，就完成了对老人的服务。

总结：通过对于中台的MCP化的准备，我们会在下一个AI时代里面占据先机，把整个企业的业务灵活性推向极致，实现有自动的适应性的、AI友好的企业中台。

谢谢大家！