MCP 协议升级测试[片段2]-程序员茄子

编程 MCP 协议升级测试[片段2]

2026-07-26 07:52:03 +0800 CST views 11

": {
"type": "string",
"enum": ["legal", "financial", "operational", "compliance"]
},
"count": {"type": "integer"},
"severity": {"type": "string", "enum": ["low", "medium", "high", "critical"]}
}
},
// v0.28+ 新增：能力语义描述
"annotations": {
"dataScope": "current", // 当前数据 vs 历史数据
"dataFreshness": "realtime", // 实时 vs T+N 延迟
"capabilityType": "scanning", // 工具能力类型：查询/扫描/分析
"requiresAnchor": true, // 是否需要先完成主体锚定
"prerequisites": [], // 前置工具依赖
"mutuallyExclusiveWith": ["risk_query_individual"], // 不应同时调用
"cacheTtlMs": 300000 // 缓存建议：5分钟
}
}


**能力分类体系的工程实践**

企查查 MCP 将工具组织为五层能力体系：

┌─────────────────────────────────────────────────────────┐
│ 全局约束层 (Global Constraints) │
│ 回答：哪些事情不能猜、不能混、不能越过 │
├─────────────────────────────────────────────────────────┤
│ SKILL 层 (Business Tasks) │
│ 回答：怎样组合多个工具完成一个业务任务 │
├─────────────────────────────────────────────────────────┤
│ Resources 层 (Stable Knowledge) │
│ 回答：调用前需要理解什么 │
├─────────────────────────────────────────────────────────┤
│ Server 层 (Capability Boundaries) │
│ 回答：这些能力属于哪个专业范围 │
├─────────────────────────────────────────────────────────┤
│ Tool 层 (Real-time Data) │
│ 回答：数据从哪里来 │
└─────────────────────────────────────────────────────────┘


这个五层体系映射到 MCP 协议：

- **Tool 层** → `tools/call` 提供原子数据能力
- **Server 层** → 多个 Tool 的逻辑分组，AI 理解"这个 Server 解决什么问题域"
- **Resources 层** → `resources/list` 提供稳定知识（术语表、数据字典、报告模板）
- **SKILL 层** → MCP Apps（新版引入），封装可复用的业务流程
- **全局约束层** → `annotations` 和 `constraints` 字段，规定使用边界

### 3.3 工具治理的生产落地

工具数量多了之后，治理变得和工具本身一样重要。2026-07-28 规范在这一点上引入了几个关键能力：

**缓存语义**

```json
// 工具级别的缓存声明
{
  "name": "company_basic_info",
  "annotations": {
    "cacheScope": "tenant",       // 租户级缓存（同一租户内复用）
    "ttlMs": 3600000,             // 缓存 1 小时
    "staleWhileRevalidate": true  // 返回旧数据的同时后台刷新
  }
}

对于企业数据查询场景，缓存策略直接影响成本。以企查查为例，每次 API 调用涉及积分消耗。如果 AI Agent 在一次会话中重复查询同一企业信息，有缓存机制可以节省大量调用成本。

限流和审计语义

// 新版网关层面的工具治理
{
  "tools": [...],
  "governance": {
    "rateLimits": {
      "default": "100/minute",
      "risk_scan": "20/minute",  // 高成本工具更严格的限流
      "company_search": "500/minute"  // 查询工具可以更宽松
    },
    "costTracking": {
      "enabled": true,
      "perToolCost": {
        "risk_scan": 10,      // 每个风险扫描消耗 10 积分
        "company_search": 2    // 每个查询消耗 2 积分
      }
    },
    "auditLog": {
      "required": true,
      "fields": ["tool", "arguments", "result_hash", "timestamp", "tenant"]
    }
  }
}

这些治理能力不是给 AI 用的，而是给 MCP 网关和平台运营者用的。网关可以基于这些元信息做限流、计费、审计，而不需要每个 Server 单独实现。

四、任务协作：从"一次调用"到"持续完成"

4.1 为什么单次调用不够用

在 MCP v1.x 的设计哲学中，每个工具调用是一个独立的事务：

用户: "帮我查一下这家公司的情况"
AI: → tools/call: company_search
AI: ← 返回企业基本信息
AI: → tools/call: risk_scan  
AI: ← 返回风险扫描结果
AI: → tools/call: shareholder_query
AI: ← 返回股东信息
AI: [整合所有结果，生成自然语言回复]

这个模式有三个明显的问题：

问题一：无法处理长任务

"帮我生成一份完整的尽调报告" 这样的任务，可能需要：

30 分钟的数据采集
多次用户确认（"这个股权结构你确认吗？"）
分阶段的结果呈现

单次工具调用模式无法支持这种多轮交互、多阶段执行的长任务。

问题二：无法处理补充输入

在任务执行过程中，可能需要用户补充信息："您想查的是注册地在深圳的总部，还是所有分支机构？" 旧版协议没有标准的方式来处理这种暂停和补充输入。

问题三：任务状态无法持久化

如果 AI Agent 崩溃或会话中断，旧版协议下正在执行的任务就丢失了。用户不得不重新描述整个任务。

4.2 MCP Apps 与任务协作的新范式

2026-07-28 规范引入了 Tasks 和 MCP Apps 作为一等公民来解决这些问题。

Tasks：长任务的持久化状态管理

# 任务创建
task = {
    "id": "task-uuid-123",
    "name": "enterprise_due_diligence",
    "status": "in_progress",
    "stages": [
        {
            "id": "stage-1",
            "name": "主体锚定",
            "tools": ["company_search", "credit_code_validate"],
            "status": "completed",
            "output": {
                "confirmed_entity": "企查查科技股份有限公司",
                "credit_code": "91110108MA01XXXXX"
            }
        },
        {
            "id": "stage-2",
            "name": "综合风险扫描",
            "tools": ["risk_scan"],
            "status": "pending",
            "prerequisite": "stage-1"
        },
        {
            "id": "stage-3",
            "name": "报告生成",
            "tools": ["report_compile"],
            "status": "pending",
            "prerequisite": "stage-2"
        }
    ],
    "progress": {
        "completed": 1,
        "total": 3,
        "pct": 33
    }
}

这个任务结构意味着：

任务执行可以被暂停和恢复
每个阶段的输出被持久化，后续阶段可以直接引用
用户可以在任何阶段介入确认或补充信息
即使 Agent 重启，也可以通过 task ID 恢复执行

MCP Apps：可复用的业务流程封装

如果说 Tasks 是单个任务的状态管理，那么 MCP Apps 是更高层次的能力封装——将多个工具、多个任务组合为一个可复用的"应用"。

// MCP App 示例：企业尽调应用
{
  "name": "enterprise_kyb_app",
  "version": "1.0.0",
  "description": "企业 KYB（了解你的客户）核验应用",
  "stages": [
    {
      "name": "entity_anchor",
      "description": "确认要核验的企业主体",
      "requiresUserInput": true,
      "validation": {
        "requiredFields": ["company_name", "credit_code"],
        "uncertaintyThreshold": 0.7
      }
    },
    {
      "name": "risk_comprehensive_scan",
      "description": "综合风险扫描",
      "parallelTools": ["risk_scan", "litigation_query", "penalty_query"],
      "aggregation": "union"
    },
    {
      "name": "shareholder_analysis",
      "description": "股权结构分析",
      "requiresUserConfirmation": true,
      "confirmationPrompt": "股权穿透结果显示有VIE架构，请确认是否继续深入分析"
    },
    {
      "name": "report_generation",
      "description": "生成核验报告",
      "outputFormat": "structured_json_with_evidence",
      "evidenceFields": ["data_sources", "query_timestamps", "confidence_scores"]
    }
  ]
}

MCP Apps 的价值在于：企业可以把最佳实践封装为可复用的应用模板，而不需要每次都重新描述任务流程。

4.3 多轮交互的工程实现

新版 MCP 支持补充输入的标准机制：

# 用户补充输入
await client.send_input({
    "task_id": "task-uuid-123",
    "stage_id": "entity_anchor",
    "input": {
        "company_name": "企查查科技股份有限公司",
        "credit_code": "91110108MA01XXXXX",
        "confirmed_by": "user_id_456"
    }
})

#

复制全文生成海报 MCP AI Agent

编程 MCP 协议升级测试[片段2]

四、任务协作：从"一次调用"到"持续完成"

4.1 为什么单次调用不够用

4.2 MCP Apps 与任务协作的新范式

4.3 多轮交互的工程实现

推荐文章