MCP 退款审核实战：人工确认、长任务与 MCP Apps

前面几节，咱们已经把 MCP 最重要的调用流程跑通了。

Host 可以连接本地或者远程 MCP Server，发现 Server 提供的 Tool，再把模型提出的调用请求交给 MCP Client 执行。

之前的订单查询、退款判断和天气查询都有一个共同特点：Tool 被调用以后，100% 能返回最终结果。

流程大概是这样的：

但是！真实的企业任务不一定能这么顺利呀。。

比如说，咱们现在要做一次批量退款审核。

这个时候，MCP Server 收到三笔订单，那么就可能会遇到下面这些情况：

• 第一：其中包含高风险退款，必须先让用户确认是否继续
• 第二：审核任务需要处理几千笔订单，短时间内处理不完
• 第三：审核结束以后得到一份复杂报告信息

这个时候，一次普通的 Tool 调用就不太够用了。

所以，从业务上看，咱们至少要完成以下三种能力：

1. Human-in-the-Loop： 高风险操作执行以前，需要让人参与确认
2. Tasks：任务短时间内无法完成，需要支持异步执行和进度查询
3. MCP Apps：复杂结果不适合只返回文字，需要通过交互界面展示

咱们一个个来看

Human-in-the-Loop

Human-in-the-Loop 翻译过来叫作 人在回路。

这玩意听起来挺抽象的，但是意思并不复杂。他指的是：

Agent 执行到某个关键步骤时先暂停下来，把信息交给人检查。只有人明确同意以后，Agent 才能继续执行。

为什么必须这样做呢？

因为模型给出的 Tool 调用，最终还是一次概率判断。

模型可能选错 Tool，也可能生成错误的参数。

就算模型判断没有问题，用户本身也可能临时改变主意。

如果调用的只是天气查询、订单查询这种只读 Tool，偶尔判断错一次，通常还好，问题不大。

但是，如果是 删除知识库、批量退款 这种操作，就不一样了

这些操作一旦执行错误了，那么就会产生很大的影响

所以，一个企业级别的 Agent 一定需要知道：哪些步骤可以自动执行，哪些步骤必须停下来交给人决定。

那么问题来了。

MCP Server 发现需要用户确认以后，应该怎样把这个问题交给用户呢？

有同学可能会说：“弹个框不就行了吗？”

不行的

因为，MCP Server 可能运行在企业服务器上，它根本不知道用户使用的是网页、桌面客户端还是命令行。

所以，Server 只能告诉 Host：“我现在还不能继续执行，需要你帮我向用户收集一项信息。”

Host 收到请求以后，再决定使用网页弹窗、桌面表单还是终端输入来询问用户。

MCP 把这种 “Server 请求 Client 帮忙收集输入” 的行为叫作 Elicitation。

整个流程长成下面这样：

比如，Server 可以返回下面这样的内容：

{
  // 表示当前请求还没有执行完成。MCP Server 在继续处理之前，还需要 Host 补充一些用户输入。
  "resultType": "input_required",
  //  Server 需要 Host 收集哪些信息
  "inputRequests": {
    "confirm": {
      // 指定本次输入请求使用 MCP Elicitation 机制。
      "method": "elicitation/create",