腾讯大模型应用演进之路：从 RAG 到 MCP 的技术实践

01

腾讯大模型应用场景

首先和大家分享下大模型在腾讯中的应用场景。

1. 腾讯大模型应用场景

腾讯业务丰富多样，涵盖微信生态、内容生态、游戏、广告等多个领域，大模型在这些业务中的应用主要集中在以下几类场景：

• 内容生成，助力微信生态内容创作、文案生成、翻译、文案润色、输入联想、素材生成等，为业务提供丰富的内容支持；

  
  

• 内容理解，实现图文匹配、实体提取、恶意判断、标签提取、诈骗识别、文本审核、问题推荐、情绪理解、文档提取、文本摘要、文本分类等功能，应用于社交平台内容管理、用户反馈分析等场景；

  
  

• 智能客服问答，在各个应用中高效帮助用户定位问题并解答，提升用户服务体验，还包括智能客情、优化建议等功能；

  
  

• 开发 Copilot，辅助开发人员进行代码评审、自动化测试、代码生成、代码解读、自动补全等工作，提高开发效率;

  
  

• 角色扮演，在游戏场景中，大模型用于角色扮演、情感陪伴、游戏 NPC 剧情演绎、游戏会话、辅助评论等，增强用户交互体验；

  
  

2. 大模型应用技术及发展

腾讯大模型应用技术主要包括模型精调、检索生成和 Agent 三大类，且在不断发展演进：

• 后训练技术，随着 DeepSeek 发布 R1 推理模型和相关技术，从 SFT 逐渐向强化学习、模型蒸馏方向发展，后训练技术旨在将业务领域知识固化到模型中，使模型能直接输出结果，提高内容生成速度，但存在知识更新成本高和幻觉问题；

  
  

• 检索生成技术,从 RAG 发展到 GraphRAG。RAG 通过从外部知识库检索信息增强生成模型回答质量，适用于通用问答；GraphRAG 在此基础上引入图结构，实现多跳推理和复杂上下文建模，解决 RAG 在处理长上下文和复杂实体关系时的不足;

  
  

• Agent 技术，从 Function Calling 演进到 MCP。Function Calling 是大型语言模型通过 API 调用预定义函数执行特定任务的机制；MCP 是开放的标准化协议，通过客户端-服务器架构实现 LLM 与外部资源的双向交互，支持复杂上下文管理，为 Agent 应用带来新的开发范式；

  
  

3. 太极一站式大模型应用解决方案

接下来介绍太极平台如何以一站式方式支持大模型应用的开发与落地。太极平台是腾讯内部最大的机器学习平台，底层统一管理公司绝大多数 GPU 及存储资源，实现算力与任务调度。在此基础上构建的混元一站式平台，作为公司内部的集样本构建、大模型训练、大模型服务及大模型应用于一体的一站式平台，具备丰富的模型库，可接入文本、多模态、语音等各类模型。

该平台支持两大核心方向的应用：

• 大模型开发：涵盖数据管理（训练数据抓取与管理）、模型训练（支持 Full/Finetune/LoRA/DP/RLHF 等多种方式）、模型评测（在线调试与多人众评）及模型服务（模型部署与推理量化），以模型训练和推理的方式供用户使用；

  
  

• 大模型应用：结合索引技术与外部工具插件（如搜索增强、自定义插件、网址解析、安全审核等），搭建 Agent 及 MCP 应用，实现智能化场景应用，例如智能问答 Agent、角色扮演 Agent、MCP 应用及自定义编排等；

  
  

目前，混元一站式平台已支持公司 TEG、CDG、WXG、PCG、IEG、CSIG 等各大 BG 的众多业务运行，为大模型应用的开发与落地提供了全面且系统化的一站式支持。

4. 太极 Agent 应用解决方案发展演进

接下来分析太极 Agent 应用解决方案的技术发展与演进及其带来的变化。在内容检索生成方向，首先是 RAG（检索增强生成）技术，其原理是用户发起查询（query）时，从外部知识库检索相关知识，大模型基于此参考进行回答。与模型微调（SFT）等方式相比，RAG 能有效减少大模型的幻觉问题，同时保障知识更新的实时性。然而，当知识涉及长生命周期内容或复杂的人物、事件关系时，RAG 便难以应对。为此，微软提出 GraphRAG 技术，通过引入图结构，利用知识图谱的实体关系网络实现多跳推理与复杂上下文建模，解决了 RAG 在复杂场景下的局限性问题。

在 Agent 技术方向，大模型本身仅具备内容理解与生成能力，缺乏执行外部工具的能力（即 “有大脑无手脚”）。为此，OpenAI 提出 Function Calling 技术，使大模型能够理解用户问题及可用工具的模式（schema）描述（如工具作用、输入输出参数），从而将用户问题与工具进行映射。例如，用户查询天气时，调用天气预报工具并输入城市 / 编码、日期等参数以获取结果。尽管 Function Calling 为大模型增添了与外部交互的“手脚 能力，但它存在训练成本高的问题，且当模型训练效果不佳时，稳定性及对用户意图与工具的理解会出现偏差。

针对上述问题，去年 11 月 Anthropic 发布了 MCP（开放标准化协议），该协议规范了大模型与外部工具的交互，清晰描述了双方交互的协议与接口。春节后，随着 Manus 通用智能体的出圈，MCP 技术得到广泛推广。目前，各厂商正积极适配 MCP 技术以实现应用落地，腾讯的太极机器学习平台也正朝着这一方向持续演进。

下面，重点分享下 RAG 技术以及 Agent 相关技术。

02

RAG 技术原理及优化实践

1. RAG 技术介绍

接下来详细介绍 RAG 技术的原理，其主要包括数据准备与知识库构建、知识召回与生成增强两个阶段：

• 数据准备与知识库构建：

  
  

  原始数据处理：将各类异构的原始数据（如 web 文档、Word、PDF 等）进行清洗与格式转换，完成信息抽取，使其便于后续处理；

  
  

  文档切片（Chunking）：将处理后的文档分割成较小的片段，避免大模型处理时超出上下文长度限制，同时提升模型生成回答的速度；

  
  

  向量化存储：通过 embedding 模型将切片后的文档转换为向量，存储至索引数据库，实现非结构化数据到结构化向量表示的转换，为高效检索奠定基础。

  
  

• 知识召回与生成增强：

  
  

  检索阶段：用户输入问题后，用相同的 embedding 模型将问题转化为向量，通过向量匹配技术在索引数据库中检索与用户查询（query）最相似的向量及对应的原始文档片段（chunk）；

  
  

  生成阶段：将用户 query 与检索到的相关 chunk 一同输入大模型，约束大模型基于这些可信的事实依据进行回答，而非依赖“预测下一个 token”的方式；

  
  

RAG 技术具有以下优势：

• 减少幻觉：基于外部知识回答，避免大模型随意生成不可靠内容；

  
  

• 更新及时：知识库（如帮助文档等）更新时，可独立于模型快速同步，确保知识时效性；

  
  

• 可解释性：回答可追溯至具体参考文档，便于理解回答依据；

  
  

• 安全隐私：相比无约束的生成方式，在数据管控与隐私保护方面更具优势；

  
  

通过这两个阶段的协作，RAG 技术实现了利用外部知识增强大模型回答的质量与可靠性，为实际应用提供了更高效、准确的解决方案。

在腾讯内部，RAG 技术尽管原理简洁，但应用颇为广泛，相当比例的业务正是基于该技术实现。深入剖析其检索环节，可分为两种匹配方式：一是 query 与 doc 的匹配，二是 query 与 question 的匹配。这一差异源于知识库组织形式的不同 —— 知识库既可以是单纯的文档片段，也可以由 question 关联对应的 doc 构成。若为前者，当用户输入问题时，系统会计算 query 与 doc 的相似度；若为后者，则直接查询用户 query 与 question 的匹配关系。显然，知识库的构建过程与质量把控，是 RAG 项目成败的关键因素。实际应用中，我们借助离线或在线实时更新的方式，将原始文本知识库通过向量计算后存储至 Vector DB，随后通过 RAG 技术召回相关文档，最终交由大模型生成回答，这便是 RAG 技术的基本原理。

2. RAG 应用关键挑战

在 RAG 应用落地过程中，面临着诸多关键挑战，具体如下：

• 首先是多格式内容提取。原始数据格式丰富多样，像 PDF 等复杂文档，解析时不仅要准确提取内容，还得保证知识的结构与关联性不受影响。比如公式、表格的识别提取，以及文本、图片、表格嵌套时的处理，都是难点；

  
  

• 其次是文档切分。切分方式至关重要，是按固定长度，还是依语义完整性？若遇到 Markdown 这类有天然目录结构的文档，又该如何处理？需针对不同格式文本选择合适切分方式，确保文档切片后语义完整；

  
  

• 再者是知识库构建。知识库在 RAG 中作用关键，若用户没有问答对（QA），或只有少量 QA，如何帮助其构建知识库？同时，如何确保知识更新的时效性？比如在缺乏足够 QA 时，怎样扩充知识库，怎样让知识及时同步，都是需要解决的问题；

  
  

• 然后是文档召回。召回时，如何保证用户查询（query）与关联文档的关联性？通过多种技术召回内容后，又该如何融合这些召回结果？例如，不同方法召回的文档，怎样整合才能提升整体关联性。

  
  

• 最后是内容生成。即便召回文档准确，模型生成答案时仍面临挑战。比如，如何确保模型跟随指令？如何解决数据隐私与安全问题？怎样提升模型回答效果，让其具备领域知识？这些都需要处理，包括回答的格式、效果优化等；

  
  

围绕这些问题，我们接下来了解下具体的解决方式。

文档解析部分，联合公司内部其他团队，打造了一个综合性模型，通过一系列编码过程来解析多种格式的内容输入。首先，利用视觉编码模型，以视觉化方式去理解文档，包括其结构和文字内容本身。接着，通过融合模型将编码后的内容进行融合，最后借助文本解码模型，把编码后的内容解码成纯文本，生成原始文本（raw text）。 实际使用中，这个模型优点显著。它能解析各种各样的文本元素，像图片、表格、段落、页眉页脚等都不在话下。应用场景也非常广泛，无论是发票、杂志，还是海报等都能处理。算法方面，它不是单一简单的算法，而是涵盖文档结构排版分析、文字 OCR 识别、表格识别等多种能力，非常全面。整体下来，在各类文本解析上能达到很高的准确率，这个水平在业内也是比较领先的。

解析完文档后，接下来就是文档切分。我们依据业务特性，提供了多种切分方式：

固定长度文本切分：

• 按照固定文本长度切分，不同分块间可有固定长度的重叠内容，保证切分的规则性。 

  
  

• Markdown 标题切分：利用 Markdown 的原生标题（一级、二级、三级等）来分割文本，将相同标题级别的文本片段归到同一个 chunk 中，适合有明确标题结构的文档。 

  
  

• 递归文本切分：通过一组分隔符（如换行符、句号等）进行分层迭代切分，把输入文本分成更小的块，适应特定符号分隔的文本。

  
  

• 中文语义切分：借助模型基于语义进行切分，由模型判断切分位置，确保切分后的内容语义完整，更智能地处理中文文本。 

  
  

通过提供这些多样化的切分方式，用户可根据自身数据特点和业务需求灵活选择，以达到最佳切分效果。

在构建高质量知识库方面，我们采用大语言模型自动生成问答对的技术，主要包含以下三种方式：

• DocQAGenerator：直接基于原始文档生成可能的问答对（QA 对），从文档内容出发，挖掘用户可能提出的问题并匹配答案。 

  
  

• AugmentedQuestionGenerator：当用户提供少量 <问题，上下文>（<Question, Context>）对时，基于现有问题和上下文，为上下文生成更多可能的用户问题，扩展问答对的覆盖范围。

  
  

• AtomicUnitsQAGenerator：参考去年年中发布的论文实现。首先将原始文本切分为若干块（chunk），再将块分解为原子陈述，然后针对这些原子陈述（以块为上下文）生成一组合成问题。这种方式生成的问题更为精细，对同一篇文章内容，能生成更多问答对，从而在解答用户问题时，知识库基本可覆盖用户可能提出的所有问题，提升知识覆盖的全面性。

  
  

通过这些离线知识扩充技术，有效解决了知识库构建中问答对不足或生成单一的问题，为 RAG 应用提供更丰富、高质量的知识基础。

在索引召回技术方面，团队采用自研的 embedding 模型，同时配备多个规格的 embedding 模型，用于对输入文本内容进行编码。此外，引入 BM25 技术，它是 TFIDF（词频 - 逆文档频率）技术的改进版本，能够基于关键字实现匹配。因此，我们的召回技术主要包含两种方式：embedding 召回和 BM25 召回。对于 embedding 召回，运用近似最近邻（Approximate Nearest Neighbor）检索技术，该技术可快速在向量数据库中召回与用户查询（query）的embedding最匹配的内容，有效提升检索效率。通过这两种召回方式的结合，实现更精准、高效的知识检索，为后续的内容生成提供可靠的信息支持。

接下来介绍更上层的方案——多路召回的 rerank 技术。一般来说，单路召回的内容可能无法全面覆盖用户的查询（query），这种情况下就需要多路召回技术。多路召回的概念更为广义，它并非局限于从多个向量数据库检索，而是可以通过多种方式进行召回，例如从向量数据库、其他搜索引擎，甚至是外部 API 调用等，这些都属于多路召回的范畴。 

召回完成后，我们会基于一个 rerank 模型，对用户的 query 与召回的内容进行细粒度的重排。重排结束后，选取排名靠前（top）的结果，将这些经过排序的内容输入到大模型中，供其参考回答。通过这种 rerank 技术，能够使回答用户问题的效果和知识覆盖范围更加全面，确保更精准地满足用户需求。

最后讲讲如何回答用户问题。当召回内容后，需要精心调整 Prompt，使其更好地理解用户问题并完成回答。具体实践中，要将 Prompt 定义清晰，包括明确角色、要求、输入输出格式，并添加一些示例，帮助模型更好地理解。从文档解析、分片，到最终的模型与 Prompt，每一个环节都要保证高质量，如此才能实现 RAG 应用的高质量落地。有些用户可能认为，简单整合代码或模型后，模型就能良好回答问题，这其实是误区。在整个过程中，知识准备、文档切片方式等各个环节都做到位，才能达到理想效果。以上就是我们在 RAG 技术方面的介绍与应用落地的情况。

03

GraphRAG 技术及应用

1. RAG 局限性

接下来我们看看 GraphRAG 的应用。比如现在问个问题：“孙悟空的如意金箍棒是怎么来的？” 从知识层面看，金箍棒是太上老君用九转镔铁炼制，大禹治水时用来测江河深浅，治水后成为东海定海神针，最后东海龙王把它给了孙悟空。这涉及到很长的上下文。在小说或剧情场景中，简单的片段召回无法回答这类问题，需要对整个章节甚至全部内容有更深入的理解才能解答。这时就会发现，普通的 RAG 技术难以做到这一点，因为它在处理复杂长上下文及实体关系推理时存在局限。

2. GraphRAG：基于图的检索增强方法

在 RAG 技术难以应对复杂长上下文问题时，我们就会引入 GraphRAG 技术。这其实是很自然的，因为在大模型出现之前，自然语言处理中 Graph 技术就是很重要的一部分，所以随着大模型发展，我们很自然地将这两者关联起来。简单来说，GraphRAG 与 RAG 技术的使用流程非常一致。首先是建索引，也就是把知识以图（Graph）的形式表示出来；第二部分是召回（retrieval）阶段，将用户的 query 在图知识库中关联上下文进行检索；最后让大模型进行回答。

应用 Graph 技术后，它展现出诸多优势：对长上下文的理解更出色，知识整合能力更强，面对如 “奥巴马的妹妹的老公是谁” 这类复杂问题时，推理能力显著提升。此外，和 RAG 技术类似，它也具备很强的可解释性。

业务里的具体应用：就拿《长相思》电视剧剧本来说，我们在原版基础上对剧中人物进行构建，通过 GraphRAG 技术给剧本做图索引，构建知识库。整个过程是这样的：首先对文档进行切片，切完片后，用一个专门生成图的 prompt，让大模型从这些切片（chunk）里提取其中的关系、实体以及它们之间的联系。最后生成人物、事件、地点等实体，还有实体间的关系，比如谁和谁是兄妹关系，谁和谁是情敌关系，另外还有局部社区聚合后的 community report（社区报告）以及 embedding（向量化）表示。这样一来，在图（Graph）里知识的表示方式更复杂，而且通过多种形式组织起来。

应用了 Graph 之后，在剧情或角色扮演类的场景中，就能解决 RAG 技术的一些不足。比如问“你是谁？你母亲是谁？你的整个故事是怎样的？”这类问题时，就不是单纯从某一章节片段找知识，而是从人物发展的整个生命周期，以及该人物和其他人物的关系等方面去全面回答，这样就能更准确、更全面地回应用户的问题了。

04

Agentic 与 Function Calling 技术

1. Agent 应用及技术原理

接下来我们进入第二部分的应用，也就是 Agent 和 MCP 这一块。之前咱们看了 RAG 和 GraphRAG 技术，它们主要用在问答场景中，根据用户问题，参考检索到的知识来回答。但还有另一种场景，能不能让大模型帮我们做事呢？比如给大模型一个任务，让它安排一次出行计划，这个计划有时间、预算、天气等约束条件。这时就会用到 Agent 技术。Agent 具备思考、观察和执行的能力。思考是指理解和规划用户的问题，执行（action）是调用外部工具，观察（observation）是根据工具执行结果进一步思考下一步行动，通过这样一步步迭代，最终完成用户的任务。

上图是基于大语言技术的 Agent 被引用最广泛的一种定义方式。它其实是一种高级的 AI 系统，能够基于复杂的上下文进行顺序性理解，还可以思考、记忆回答的上下文，并且能使用外部工具，最终完成复杂的问题。所以从这里看，它具备规划（plan）功能、记忆能力，以及执行外部工具的能力。

2. Function Calling 在太极中的实现及应用案例

在太极平台中，Function Calling 的实现是这样的：我们设计了一个精巧的 prompt，让模型执行 COT（思维链），根据用户需求和工具执行等输入，输出类似 plan、action 等结构化数据格式。

举个例子，当用户发起一个查询（query），比如 “帮我定一张明天的票”，planner（核心大模型）会先思考。此时模型发现信息不完整 ——订什么类型的票（飞机票还是火车票）？从哪个城市到哪个城市？于是模型会通过反复反问、确认，让用户补充更完整的信息。经过多轮交互，当模型认为信息足够时，就会调用外部工具，执行查询或订单相关操作。如果操作中出现错误，它还有重试机制。最后，当所有任务都完成，模型就可以给用户最终的回答了。整个过程就是在太极平台中基于 Function Calling 的实现，通过这样的方式让大模型更智能地完成用户任务。

接下来看一个应用实例，在与腾讯云合作的业务场景中，涉及合作伙伴及交付等业务。我们借助 Function Calling 技术，实现了“一句话完成工作” 的便捷操作，例如查看任务执行历史、创建任务等。最终，我们将这种能力集成到产品中，用户只需通过一句话就能触发这些操作。在执行过程中，Function Calling 会自动筛选并调用合适的基础组件来完成相应工作。这便是 Function Calling 在实际业务中的一个典型应用。

05

MCP-Agent 应用新范式

最后了解下，MCP 新技术引入后，对 Agent 应用范式的影响。

1. MCP 技术及生态

先看 MCP 协议，它的全称是 Model Context Protocol（模型上下文协议），这里的“上下文”更多指模型与外部工具交互的上下文。从图示中可以看到，重点是模型与外部工具的交互部分，通过 MCP 协议的定义，能让这种交互以更标准化的方式执行外部工具。 具体看 MCP 技术的组成：

• MCP host：简单理解为一类应用，包括桌面应用（如 Claude Desktop、Cursor IDE）、智能助手（如 Cherry Studio 等）。在这些应用里，集成了 MCP client 的 SDK（比如 Python SDK），负责在 host 应用中与 MCP server 交互。 

  
  

• MCP server：是一个个原子服务，由不同厂家或社区开放，针对特定任务集合。例如，文件操作（读取、更名、删除等可归到 file system 服务）、不同数据库操作、其他外部服务等，都可由 MCP server 提供。

  
  

执行过程中，MCP client 与 server 之间通过标准输出或流式 SSE 等协议交互，MCP server 则对接外部工具、资源（如文件系统、数据库）、prompt 等。 需要补充的是，MCP host 不仅指安装了 MCP 应用的程序，还包括应用所在的主机。比如，当应用需要调用浏览器或进行文件系统操作时，就会用到主机上的系统应用或文件系统。所以，MCP host 的范围涵盖了应用、主机及主机上的资源（文件系统、其他应用等）。

现在详细看一下 MCP 在 Agent 执行中的运作流程：当用户发起问题时，大模型本身仅有“大脑”（理解能力），而无“手脚”（执行外部工具的能力）。处理用户请求时，MCP 负责为模型赋予“手脚”。具体步骤如下： 

• 输入整合：用户发起查询（query）后，系统将用户的 query 与可用的 MCP server 及其中工具（tool）的描述一同发送给大模型；

  
  

• 模型决策：大模型理解用户问题与工具描述后，判断是否需要调用工具。若需调用，输出包含工具名称与参数的 JSON 格式数据，明确调用目标；

  
  

• 工具调用：通过 MCP client 调用对应的 MCP server，获取工具执行结果；

  
  

• 迭代处理：将用户 query、可用工具、已执行工具及其结果再次反馈给大模型，重复上述调用或规划过程，直至大模型反馈“stop”，表示任务完成；

  
  

• 结果反馈：将最终结果返回给用户；

  
  

这一过程设计精妙，通过自然语言或文本描述动作，多次迭代调用大模型，依据其输出决定执行工具或结束工作。如此一来，Function Calling 更明确，各厂家在标准化的 function 描述下优化模型，使调用外部工具的流程更加统一规范，展现了 MCP 处理用户 query 时完整且有序的技术调用链路。

MCP 技术给开发范式带来的变化。在 MCP 出现前，若想让大模型具备调用外部工具的能力，每个厂商都需在自身应用中分别实现不同厂家工具的调用，同时描述工具的 schema。这引发了一些问题：一方面，相同工具在不同厂家的调用实现需各自进行，且技术与方式各异，导致使用效果差异较大；另一方面，应用开发者调用这些工具时，对工具的熟悉度和特性理解可能不够全面。

而 MCP 出现后，情况有了显著改变。首先，工具的提供者不再是应用开发者，而是真正的服务提供者，他们可通过 MCP 方式开放自己的服务。以往业界通常以 API 方式暴露服务，如今有了新选择——MCP server，这在 AI 大模型时代，相当于提供了一种类似 API 的全新服务对外开放形式。对比传统的 function calling，其差异在于 MCP 构建了服务或外部工具与大模型之间的接口。当这个接口和桥梁确定后，后续工作便是让大模型更好地兼容该协议，同时各厂家能在 MCP上开放自身服务。这便是 MCP 为 Agent 应用及开发带来的范式转变。

接着了解下 MCP 的技术生态系统。右边这张图是 a16z 公司发布的 MCP 市场地图。从图中能看到，一般关注这几个部分： 

• 第一部分是 MCP 应用，也就是哪些应用已支持 MCP 技术。大家可以去这个网站查看，目前大概收录了两百多个应用（不过这只是部分，企业级应用未算在内，这些大多是桌面或应用端的），像代码助手、智能助手之类的应用已经非常多了；

  
  

• 第二部分是 MCP server，即以这种方式提供服务的应用，其数量增长极快。短短二十天内，主流 MCP 市场上托管的 MCP server 数量甚至翻倍，整个生态正以惊人的速度发展；

  
  

• 第三部分是 MCP marketplace，能看到一些主流的，比如 MCP.so 之类的通用 MCP server，还有像 Cursor 这样的 IDE 对应的 MCP server；

  
  

从过去半个月到一个月的情况看，MCP 生态发展极为迅速。应用支持越来越多，各个厂商纷纷拥抱 MCP（前段时间 OpenAI 也宣布支持），能 MCP 化的服务也日益丰富，整个生态系统正不断壮大。

2. 太极 MCP 平台架构及发展思考

了解完 MCP 生态后，再来了解下 MCP server 在太极平台的应用。MCP 应用很多是桌面端的，但企业内部应用场景不同，安全和风险管理要求更高。在太极平台，我们从 MCP server 开发和 MCP 应用两部分来实现。 

• MCP server 开发：内部私有的 MCP 市场，考虑到企业内部对安全、信息安全和风险管控更严格，不会直接拉取外部公开市场的 MCP server（避免注入、后门等问题），而只能拉取注册在腾讯内部镜像源的 Python 库或 NPM 包。平台集成了 MCP Server 开发环境，支持 Python、TypeScript 等语言及 MCP 客户端环境，方便用户开发（内部 IDE 也基于此镜像开发）。 对接内部代码仓库，还计划将原有 agent 平台上按平台规范实现的用户插件，转成 MCP server 并快速注册到平台；

  
  

• MCP 应用： 原有 agent 应用运行时，增加 MCP 执行组件。用户通过编排选定要使用的 MCP server 后，运行时会注册 Meta Data（包含软件镜像中的包及访问这些包的 token）。 执行时，以 runtime sandbox（运行时沙箱）方式运行 MCP server，在沙箱内对网络、文件系统、资源访问进行限制，最大程度保障 MCP 执行的安全性；

  
  

这就是我们在企业内部对 MCP 协议的支持与实现，既满足企业安全需求，又方便开发与应用。

对 MCP 发展的思考：MCP 是个很新的技术，我们以乐观积极的态度对待它。如果 MCP 发展得好，会带来哪些变化呢？

• Open API 化。在大模型技术背景下，MCP 很可能成为一种新的技术或服务开放方式，类似新的 API。各个厂商，包括 SaaS 或应用服务，能以 MCP 方式提供能力，这样在智能化应用中更容易被使用。

  
  

• 应用+智能助手。从互联网技术发展看，搜索框成应用标配，在大模型时代智能助手也逐渐成为很多应用的新入口。交互方式变为语音问答或指令，场景从搜索内容转向端到端完成自动化任务。比如在企业微信里说 “预定明天某时段的会议，邀请 ABC 同事”，或“审批某个电子流”、“提交请假”等，都能成为自动化对象。 

  
  

• E2E 自动化。端到端理解用户意图、执行任务、处理容错，大大简化用户业务流程。就像前面的例子，用户不用自己操作多个步骤，系统自动完成。

  
  

• 生态重构，开放协作。支付、生活服务、内容服务等作为基础能力，实现你中有我、我中有你，拓展服务生态的协作开放。比如对智能助手说 “定一杯咖啡，用某快递送给某人”，可能集成支付、商家、物流等能力。

  
  

这样用户无需在各个应用间切换，通过指令在一个入口完成复杂业务。虽然从商业化角度，厂商可能有能力壁垒，但从技术发展和未来改变看，值得这样思考。