從無狀態核心到可信能力閉環：能力發現、結構化交付、鏈路追蹤與任務協作
導讀：2026 年 5 月，MCP 發佈了2026-07-28規範候選版。這是 MCP 自推出以來規模最大的一次修訂。MCP 正從“讓 AI 會調工具”的連接協議，走向可規模運行、可治理、可追蹤、可擴展的生產級基礎設施。其背後包括無狀態核心、能力發現、完整 JSON Schema、標準化鏈路追蹤、授權加固，以及 Extensions、Tasks 和 MCP Apps 等變化。本文結合企查查 MCP（https://agent.qcc.com）的實踐，討論企業數據如何從 API 時代的“字段可調用”，走向 Agent-Native 時代的“能力可發現、主體可確認、結果可結構化、過程可追蹤”，為 AI 智能體注入真實的商業世界。
一、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 的四個生產化信號
二、企查查十餘年演進：從 API 到 MCP，讓 AI 用對企業數據
企查查過去十餘年的產品演進，恰好對應企業數據交付方式的三次變化：信息檢索讓人查到企業，API 讓業務系統用上企業數據，MCP 則讓 Agent 理解任務、選擇能力並交付可追溯結果。
信息檢索：讓人查到企業
企業信息檢索網站將原本分散的工商、股權、司法和經營信息組織為可查詢的企業檔案，解決“數據有沒有”。
API 開放：讓業務系統用上企業數據
隨着企業數據進入 CRM、信貸、風控和內部業務系統，企查查通過 API 開放平臺交付字段、接口和文檔，解決“數據能不能用”。
Agent-Native：讓 AI 用對企業數據
進入 Agent 時代，用戶不再按字段編寫固定流程，而是用自然語言提出任務。Agent 需要確認主體、選擇工具、讀取數據並組織證據，解決“AI 能不能用對數據”。
API 時代從“我有什麼數據”出發；Agent-Native 時代則從“AI 要完成什麼任務”出發，除了實時數據，還要交付工具語義、業務邊界、知識資源、任務方法和證據鏈。
企業數據接口正在從“能調”，走向“能選”，最終走向“會用”。
賦予大模型“背景穿透”的商業直覺，不是讓模型憑經驗猜測，而是讓它穿透名稱、股權、歷史、司法和經營關係，回到真實商業世界中的確定主體與確定事實。
圖 2 · 企查查企業數據服務的三次演進
三、企查查 MCP：不是工具箱，而是能力矩陣
截至 2026 年 7 月，企查查智能體數據平臺（https://agent.qcc.com）已經形成三類 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 的五層能力矩陣
四、無狀態與能力發現：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 用好。
五、一條企業盡調任務：查對、選對、讀對、說清
以金融機構常見的企業身份核驗（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 · 企業盡調任務的可信執行鏈
六、知識、結構、證據與任務：新版協議的企業能力閉環
無狀態解決“服務怎樣運行”，能力發現解決“工具怎樣被找到”。要讓企業數據真正進入業務，還需要補齊知識、結構、證據和複雜任務四個環節。
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 · 新版協議下的企業能力閉環
七、寫在最後：從接口競爭走向可信能力競爭
MCP2026-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 回答企業問題，靠真實數據，不靠記憶和搜索；讓每一個結論，都能回到確定主體、明確工具和可追溯來源。
動手試一試 · 企查查智能體數據平臺 ·https://agent.qcc.com
為 AI 智能體注入真實的商業世界。企查查智能體數據平臺目前已適配WorkBuddy / QoderWork / QClaw / IMA / MiniMax / LobsterAI等主流 AI 工具，並支持通過標準 MCP 配置接入其他兼容 MCP 協議的 AI 客戶端。平臺提供企業數據、法律數據和智能文檔解析三類 MCP 服務。
9 個 Server · 197 個工具 · 27 個業務 SKILL
訪問 https://agent.qcc.com，獲取 API Key、接入配置與使用指引
參考資料
1、MCP 官方博客：The 2026-07-28 MCP Specification Release Candidate，2026-05-21。
2、企查查智能體數據平臺：https://agent.qcc.com。
分享嘉賓
杜虎｜ 企查查科技股份有限公司 · 技術總監