导读

2026 年 5 月，MCP 发布了 2026-07-28 规范候选版。这是 MCP 自推出以来规模最大的一次修订。MCP 正从“让 AI 会调工具”的连接协议，走向可规模运行、可治理、可追踪、可扩展的生产级基础设施。其背后包括无状态核心、能力发现、完整 JSON Schema、标准化链路追踪、授权加固，以及 Extensions、Tasks 和 MCP Apps 等变化。本文结合企查查 MCP的实践，讨论企业数据如何从 API 时代的“字段可调用”，走向 Agent-Native 时代的“能力可发现、主体可确认、结果可结构化、过程可追踪”，为 AI 智能体注入真实的商业世界。

主要内容包括以下几个部分：

1. MCP 2026-07-28 到底改变了什么

2. 企查查十余年演进：从 API 到 MCP，让 AI 用对企业数据

3. 企查查 MCP：不是工具箱，而是能力矩阵

4. 无状态与能力发现：MCP 为什么开始像生产基础设施

5. 一条企业尽调任务：查对、选对、读对、说清

6. 知识、结构、证据与任务：新版协议的企业能力闭环

7. 写在最后：从接口竞争走向可信能力竞争

01、MCP 2026-07-28 到底改变了什么

2026 年 5 月，MCP 发布了 2026-07-28 规范候选版。MCP 官方将其称为协议推出以来规模最大的一次修订，最终规范计划于 7 月 28 日发布。

这次更新涉及无状态核心、能力发现、缓存、链路追踪、完整 JSON Schema、授权加固、Extensions、Tasks 和 MCP Apps 等多个方面。

把这些变化放到远程 MCP Server 的生产部署中，可以归纳为四个值得关注的生产化信号。

信号一：协议从“会话绑定”走向“请求自包含”

过去，客户端需要先建立协议会话，后续请求依赖同一份 Session。新版取消协议层 Session，每个请求携带完成处理所需的信息，可以由任意服务实例处理。

工程含义：远程 MCP Server 不必再被某次会话绑定在某台机器上。

信号二：能力从“列出来”走向“管起来”

新版增加能力发现、路由和缓存语义。工具不再只是客户端拿到的一张清单，还可以被网关识别、被客户端缓存、被平台限流和审计。

工程含义：工具越多，越需要能力治理，而不是继续平铺。

信号三：任务从“一次调用”走向“持续完成”

Multi Round-Trip Requests、Tasks 和 MCP Apps 为补充输入、用户确认、长任务和交互界面提供了新的标准位置。

工程含义：MCP 正从单次工具调用，扩展到支持补充输入、确认节点与长任务状态管理。

信号四：结果从“模型说了什么”走向“依据能否还原”

完整 JSON Schema 2020-12、W3C Trace Context 和授权机制加固，让结构、调用链和身份边界变得更加明确。

工程含义：企业级 MCP 不只交付答案，还要交付答案的结构和运行轨迹。

此外，新版把 Extensions 提升为一等公民，并建立更正式的特性弃用和演进机制。MCP 正从“快速增加能力”，走向“让能力可以独立演进，同时控制兼容风险”。

这次协议重大升级的核心，不是又增加了几种调用方式，而是推动 MCP 从连接协议走向生产级 Agent 基础设施。

图 1 · MCP 2026-07-28 的四个生产化信号

02、企查查十余年演进：从 API 到 MCP，让 AI 用对企业数据

企查查过去十余年的产品演进，恰好对应企业数据交付方式的三次变化：信息检索让人查到企业，API 让业务系统用上企业数据，MCP 则让 Agent 理解任务、选择能力并交付可追溯结果。

信息检索：让人查到企业

企业信息检索网站将原本分散的工商、股权、司法和经营信息组织为可查询的企业档案，解决“数据有没有”。

API 开放：让业务系统用上企业数据

随着企业数据进入 CRM、信贷、风控和内部业务系统，企查查通过 API 开放平台交付字段、接口和文档，解决“数据能不能用”。

Agent-Native：让 AI 用对企业数据

进入 Agent 时代，用户不再按字段编写固定流程，而是用自然语言提出任务。Agent 需要确认主体、选择工具、读取数据并组织证据，解决“AI 能不能用对数据”。

API 时代从“我有什么数据”出发；Agent-Native 时代则从“AI 要完成什么任务”出发，除了实时数据，还要交付工具语义、业务边界、知识资源、任务方法和证据链。

企业数据接口正在从“能调”，走向“能选”，最终走向“会用”。

赋予大模型“背景穿透”的商业直觉，不是让模型凭经验猜测，而是让它穿透名称、股权、历史、司法和经营关系，回到真实商业世界中的确定主体与确定事实。

图 2 · 企查查企业数据服务的三次演进

03、企查查 MCP：不是工具箱，而是能力矩阵

截至 2026 年 7 月，企查查智能体数据平台已经形成三类 MCP 数据服务：

• 企业数据 MCP：6 个 Server、185 个工具，覆盖工商、股权、风险、知识产权、经营、历史和人员信息。
• 法律数据 MCP：2 个 Server、10 个工具，提供法律法规、司法案例与引用溯源能力。
• 智能文档解析 MCP：1 个 Server、2 个工具，把原始文档转换为更适合 AI 使用的结构化内容。

合计 9 个 Server、197 个工具，并配套 27 个业务 SKILL。目前已适配 WorkBuddy / QoderWork / QClaw / IMA / MiniMax / LobsterAI 等主流 AI 工具，并支持通过标准 MCP 配置接入其他兼容 MCP 协议的 AI 客户端。

但工具数量不是产品的全部。如果只是把近两百个 API 换成近两百个 Tool，AI 仍然可能选错工具、重复调用、误解空数据，或者把当前和历史状态混为一谈。

企查查 MCP 更重要的实践，是把企业数据能力逐步组织为五个层级。

Tool：提供实时数据

工商、股权、风险、知产、经营、司法、法规和文档解析等原子工具，回答“数据从哪里来”。

Server：划分专业能力边界

按照企业数据、法律数据和文档解析等领域组织工具，回答“这些能力属于哪个专业范围”。

Resources：提供稳定知识

企查查 MCP 已适配 Resources，将术语表、数据字典、工具映射和报告模板等稳定知识按需提供给 AI，回答“调用前需要理解什么”。

SKILL：组织业务任务

将多个 Tool 组合为企业核验、受益所有人识别、尽调、风险扫描和报告生成流程，回答“怎样完成任务”。

全局约束：守住可信边界

实体锚定、当前与历史、数据时点、引用纪律和输出边界，回答“哪些事情不能猜、不能混、不能越过”。

这五层共同回答 Agent 的五个问题：我有什么能力，什么时候使用，怎样组合，结果如何解释，哪些边界不能越过。

Tool 提供实时数据，Resource 提供稳定知识，SKILL 组织业务流程。

所以，企查查 MCP 不只是工具箱，而是一套可被 Agent 编排的企业数据能力矩阵。

图 3 · 企查查 MCP 的五层能力矩阵

04、无状态与能力发现：MCP 为什么开始像生产基础设施

无状态是 2026-07-28 候选版最基础、也最容易被技术细节遮住的变化。

直观理解：无状态不是系统没有状态，而是一次请求不再依赖某台固定服务器保存的协议会话。

旧版远程 MCP 需要先完成握手并维护 Session。新版取消这层协议会话，让请求可以落到任意服务实例。技术上对应的是移除 initialize / initialized 握手和 Mcp-Session-Id。

这看似是底层传输变化，实际决定了远程 MCP 能不能自然地横向扩容、故障切换，并复用成熟的 HTTP 网关和负载均衡体系。

对于企查查 MCP，这一点尤其重要。平台面对的不是一个本地客户端，而是不同 AI 工具、合作平台、客户租户和调用规模。企业数据服务还涉及权限、积分、成本、审计和数据时效，必须在普通生产基础设施上稳定运行。

与无状态同时出现的，是能力发现与治理。

server/discover 让客户端可以按需了解服务端能力；Mcp-Method 和 Mcp-Name 让网关识别调用的方法和工具；ttlMs、cacheScope 让稳定的工具清单和资源拥有明确缓存时间。

这些字段不需要普通读者逐一记住。它们共同解决的是一个问题：当 MCP 从几个工具扩展到几十、上百个工具后，能力如何被发现、路由、缓存、限流和审计。

对拥有 9 个 Server、197 个工具的企查查 MCP 来说，能力发现也不只是“列出所有工具”，而是让 AI 理解：

• 哪些工具查企业基础信息，哪些工具查风险；

• 哪些工具查当前记录，哪些工具查历史记录；

• 哪些场景应该先做综合扫描，再对非零维度下钻；

• 哪些调用必须先完成企业主体锚定；

• 哪些相近工具不应被散弹枪式同时调用。

工具规模决定能力上限，能力治理决定这些工具能不能真正被 AI 用好。

05、一条企业尽调任务：查对、选对、读对、说清

以金融机构常见的企业身份核验（KYB）和受益所有人识别（UBO）为例。用户给 Agent 的任务通常更接近这样的真实问法：

请帮我对企查查科技股份有限公司做一份完整的 KYB 核验报告，重点核验主体真实性、股东结构及最近 3 年的司法风险。 请帮我对企查查科技股份有限公司进行受益所有人（UBO）识别，并说明股权穿透路径。

前一个任务是综合核验，后一个任务是专项穿透；同一主体、不同意图，会触发不同的工具组合与执行流程。

对于传统 API 集成，开发人员会提前确定接口顺序、字段映射和判断规则。对于 Agent，任务拆解与工具选择会在运行过程中动态发生。

一次可信执行，不是“多调几个接口”，而是完成四个动作。

第一步：查对主体

企业简称、曾用名和同名主体都可能导致查错对象。Agent 不能直接拿简称进入风险工具，而应先完成企业识别，并使用统一社会信用代码或企业唯一标识锚定主体。若存在多个候选，正确做法是请求确认，而不是猜一个最像的结果。

第二步：选对能力

风险调查不等于把所有工具调用一遍。企查查 MCP 在实际任务中采用“先扫后钻”：先执行综合风险扫描，获得各风险维度的数量和分布，再对非零、高风险或客户重点关注的维度继续查询。

这样既减少无效调用，也避免大量无关数据挤占上下文。

第三步：读对数据

Agent 需要区分当前与历史、已确认与待核实、未发现与绝对不存在。Tool 返回客观事实，AI 可以解释字段，但不能把“当前未发现公开记录”扩大为“企业绝对没有风险”，也不能替金融机构作出授信或准入决定。

第四步：说清依据

最终报告不能只有一段自然语言结论，还应保留主体标识、查询时间、使用的工具、关键字段和来源，使客户能够复核结论是怎样形成的。

这四步背后，是企查查 MCP 的信任工程：全局约束规定共同底线，Tool Description 说明局部语义和使用边界，SKILL 与 Resources 固化任务方法和领域知识。

上一篇文章已经详细讨论过三层反幻觉工程。放到新版 MCP 的语境中，新的重点不是再写一遍 Prompt，而是让约束找到更稳定的协议载体：Description 承载语义，Schema 承载结构，Resource 承载知识，Trace 承载证据。

这套体系不承诺“零幻觉”。它的目标是把 AI 的自由发挥压缩在可检查、可追溯、可纠错的边界内。对于高风险业务，AI 负责减少重复劳动，人仍然保留判断、验收和刹车的权力。

图 4 · 企业尽调任务的可信执行链

06、知识、结构、证据与任务：新版协议的企业能力闭环

无状态解决“服务怎样运行”，能力发现解决“工具怎样被找到”。要让企业数据真正进入业务，还需要补齐知识、结构、证据和复杂任务四个环节。

Resources：让稳定知识可被按需发现

一句话解释：Resource 不是另一种数据查询工具，而是供 AI 按需读取的稳定知识资产。

企查查 MCP 已适配 Resources，将术语表、工具映射、数据字典和报告模板等稳定知识，从分散的 Prompt 和说明文本中拆分出来，供 AI 按需发现、读取和复用。它们不是实时业务数据，却决定 AI 能否正确理解工具和数据语义。

Schema：让结果从自然语言走向结构化交付

新版将 Tool 的输入和输出 Schema 升级到完整 JSON Schema 2020-12，允许更完整地表达组合、条件和引用关系。

对于企业尽调，一份结果可以同时包含已锚定主体、查询时间、风险摘要、受益所有人路径、关键字段、数据来源和边界状态。自然语言负责解释，结构化结果负责进入系统、接受校验和支持复核。

Trace：让结论沿调用链回到证据

一句话解释：Trace 不是多记一份日志，而是让一条 AI 结论能够沿调用链回到具体数据来源。

新版明确了 W3C Trace Context 的传播方式。一次调用可以从 AI 应用开始，经过 MCP Client、网关、MCP Server 和下游数据服务，最终形成完整的调用轨迹。

当客户问“这条风险结论从哪里来”，平台应能回答：查的是哪个主体，调用了哪个工具，数据来自什么时点，引用了什么来源。

用户确认与长任务：让复杂流程可以继续推进

Multi Round-Trip Requests 可以在主体不唯一或参数不足时请求用户确认；Tasks 可以管理批量扫描、长报告和大文档解析；MCP Apps 可以提供候选主体选择、风险图谱和任务进度等交互界面。

这些能力并不意味着所有产品都要立即全部实现。它们更重要的意义，是为过去需要各家自行设计的确认、异步任务和交互流程，提供了更标准的协议位置。

同时，新版进一步加固 OAuth 2.0 和 OpenID Connect 授权实践，并通过 Extensions 与正式弃用政策降低未来演进的不确定性。

至此，一条企业数据任务形成了更完整的闭环：

Resources 提供知识，Schema 固定结构，Trace 留下证据，用户确认、Tasks 与 MCP Apps 推动复杂任务完成；它们与 Tool、SKILL 一起构成企业数据的可信能力闭环。

图 5 · 新版协议下的企业能力闭环

07、写在最后：从接口竞争走向可信能力竞争

MCP 2026-07-28 候选版传递出一个清晰方向：MCP 正从连接协议走向生产级 Agent 基础设施。

无状态让服务可以扩展，能力发现和缓存让工具可以治理，Resources 让稳定知识可以复用，Schema 和 Trace 让结果可以验证，Extensions 让复杂任务能够独立演进。

但协议标准并不会自动保证业务正确。企业数据服务仍然需要解决主体识别、工具选择、数据语义、时间状态和审计责任。技术调用成功，不等于业务结论可信。

企查查 MCP 的实践说明，企业数据进入 Agent 时代后，竞争点不再只是“谁有更多接口”，而是谁能让 AI 稳定、准确、低成本、可审计地使用这些数据。

从 API 到 Agent-Native 企业数据基座，本质上是一次产品范式迁移：

API 交付数据字段，MCP 交付 AI 可用的数据能力。 API 面向系统集成，MCP 面向智能体执行。 API 解决“能不能调用”，MCP 解决“能不能可信地完成业务任务”。

如果你的团队也在建设 MCP，可以先问自己三个问题：

• 第一，能否规模化运行？ 请求能否由任意实例处理，能力能否被发现、路由、缓存和治理？
• 第二，能否让 AI 正确使用？ 主体、语义、工具边界和任务方法是否足够清楚？
• 第三，能否解释每个结论从哪里来？ 结果能否回到具体主体、工具、数据时点和权威来源？

协议提供共同语言，真实业务中的可信执行，决定 MCP 最终能不能创造价值。

企查查正在做的，是把长期积累的企业工商、股权关系、经营动态、司法诉讼、知识产权等数据能力，从“人和系统可以查询”，进一步转化为“Agent 可以发现、理解、编排和审计”的企业数据基座。

为 AI 智能体注入真实的商业世界；让 AI 回答企业问题，靠真实数据，不靠记忆和搜索；让每一个结论，都能回到确定主体、明确工具和可追溯来源。

本文所述实践基于企查查智能体数据平台面向 AI 智能体的工程落地。 以上就是本次分享的内容，谢谢大家。

出品社区｜DataFun

分享嘉宾丨杜虎 企查查科技股份有限公司 技术总监

负责企查查智能体数据平台的工程落地与产品能力建设，持续推进企业数据、法律数据和智能文档解析能力进入 AI Agent 场景，实践方向包括 MCP 协议、Tool / Resources / SKILL 设计、反幻觉与可信数据链路。