Claude Code 支持服务端 MCP 长任务

Claude Code 的 MCP 长任务开始有了跨会话运行的能力：服务器接单后先返回任务，工作继续执行，客户端在后台轮询状态。原文称，这项能力已进入公开测试，起点是 CLI，要求 v2.1.304 或更高版本。

但「放到后台」并不等于「退出后还能继续」。原文最有用的地方，是拆出了等待策略、无人值守交互、恢复与取消、权限边界等六项配置决策。对接 MCP 的程序员，需要重新确认一次：任务究竟由谁执行，又由谁负责收尾。

后台调用和 MCP task，为什么必须分清

普通调用通常要等工具执行完才返回；MCP task 则先返回任务信息，再由 Claude Code 查询状态，页脚会显示类似 1 MCP task 的计数。

决定任务能否跨会话运行的，是服务器端的任务机制，而不是界面上有没有「后台」字样。

原文指出，长调用默认在两分钟后自动转入后台，但这条路径产生的是普通后台调用，并非 MCP task，退出会话后无法存续。对于真正进入后台的 MCP task，Claude Code 默认没有执行时限。普通调用的总时长限制和空闲超时，只约束服务器返回任务之前的阶段；之后，得到响应的状态查询也算活动。

作者因此建议显式决定等待行为。下面这段配置关闭 MCP 调用的自动后台化，让 Claude 等到调用结束：

{
  "env": {
    "CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS": "0"
  }
}

要看清的是值为 "0" 的那一行，它控制自动后台化。另一个变量 CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND=1，针对的是等待 MCP task 的最终结果。它们都可以放进 settings.json 的 env。

不能靠名字猜配置效果：CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 或 bare mode，本身都不会让 Claude 等待 MCP task。

任务来源同样关键。远程服务器上的任务可以在退出 Claude Code 后继续运行；stdio 服务器进程会随客户端退出而停止。除非服务器文档明确承诺任务能脱离进程存活，否则应先等它完成，或者主动停止。

无人值守任务，最怕运行到一半提问

MCP task 可以通过 elicitation，也就是向用户补充索取输入的机制，中途发起交互。Form 模式展示服务器定义的表单；URL 模式把链接交给系统浏览器，在终端外完成流程。

交互有几个容易误判的细节。拒绝或按 Esc 都算作一次回答，后续是否继续由服务器决定。打开 /tasks 面板时，输入对话框会被隐藏，需要关闭面板才能回答。URL 还有长度上限：需要转义的字符按四倍计数，因此普通 URL 大约在 8,000 字符附近触顶，大量百分号转义的 URL 大约在 4,000 字符附近触顶；超限后只能拒绝。

对自动化流程来说，更大的问题是没有人能回答。

在非交互会话中，只要任务请求输入，Claude Code 就会向服务器请求取消，而且不会执行 Elicitation hooks，也不会调用 Agent SDK 的 onElicitation。已有的自动应答 hook，不能直接兜住这条路径。

因此，经由 -p 执行的流水线，如果连接的服务器可能中途提问，就需要重新检查失败处理。v2.1.310 调整了这种情况的超时错误，让 Claude 得知没有收到回答，避免重复调用。但客户端请求取消之后，服务器如何清理已完成的部分工作，原文没有说清。

恢复任务也有明确边界：

• 执行 /clear 或 /branch 后，结果仍会送到当前对话。
• 使用 claude --resume 或 --continue，服务器重连后会重新跟踪任务，也能接收离线期间完成的结果。
• 单次 claude -p "<prompt>" 不会重新跟踪已有任务；应交互式恢复，或使用 --input-format stream-json。
• 新会话和 --fork-session 都不会接续跟踪。

取消则要在 /tasks 中选中任务并按 x，Esc 不会停止后台任务。服务器断开时，先通过 /mcp 重连；否则取消请求发不出去，Claude Code 却会忘记任务。

原文还列出一组约五分钟的状态边界：300 秒内未重连、300 秒内未接受登录、持续五分钟返回错误，以及服务器拒绝任务 ID 后最多继续询问五分钟。排障时，需要区分客户端停止跟踪和服务器停止执行。

能否启用，要同时检查版本、协议和会话

升级客户端只是第一步。原文称，v2.1.304 于 10 月 19 日发布，10 月 25 日的报道确认了公开测试状态。工具调用要变成 MCP task，还必须满足这些条件：

服务器支持 tasks，通过 HTTP、stdio 或 claude.ai connector 连接，并协商到 2026-07-28 协议版本。设置 MCP_SDK_GENERATION=v1 或 MCP_PROTOCOL_NEGOTIATION=legacy 会排除这项能力。

会话还必须获取功能开关，并且 Anthropic 已对该类会话开放。按原文描述，支持范围包括 terminal CLI、Agent SDK 和 GitHub Actions；Bedrock 等第三方提供商，以及关闭遥测或功能开关获取的配置不在范围内。VS Code extension 和 desktop app 当时也尚未支持。

v2.1.292 已开始请求 2026-07-28，此前做过协议探测的服务器可以优先检查。停留在 2025-11-25 的服务器保留旧行为，包括需要在 MCP 配置项中设置 "bareElicitationCapability": true 的 URL 提问路径。

对写 MCP server 的人，最实用的信息是：应按每次调用携带的能力声明判断是否返回任务。

在 2026-07-28 连接中，客户端能力位于 params._meta["io.modelcontextprotocol/clientCapabilities"]，其 extensions 下包含 "io.modelcontextprotocol/tasks": {}。不能变成任务的 tools/call 请求会省略该扩展，因此不能只在连接建立时判断一次。

客户端同时声明 elicitation: {form: {}, url: {}}。原文还提到 C# SDK 的 2.0 系列把调用中途索取输入做成正式往返流程，说明客户端和服务器生态正在围绕同一协议版本补齐能力，但这不代表任意服务器都已兼容。

我的判断

作者抓住了真正需要审查的变化：任务完成后，结果交给 Claude，不会直接进入对话记录，用户需要询问 Claude；如果 Claude 当时空闲，它还会自行开始处理结果。

因此，权限审查不能只覆盖发起任务的那一刻，还要覆盖结果回来之后可能触发的工具。作者建议检查 deny rules，并用 v2.1.307 引入的 safety_event 遥测观察拦截情况。这个方向合理，但原文没有提供规则配置、拦截样例或对照数据，不能据此认定已有权限方案足够可靠。

整篇也更接近文档梳理和运维建议，没有展示作者实际跑通跨会话任务的完整记录，更没有吞吐、稳定性或资源成本测试。它能帮助识别边界，不能证明这种机制一定优于现有作业队列。

和普通后台调用相比，MCP task 提供了服务器执行、客户端跟踪的分工；和独立任务队列相比，它又增加了 Claude Code 的协议、功能开关和恢复语义等依赖。已有队列系统的团队，仍需自己安排持久化与清理，不能把客户端的跟踪能力当成整套任务保障。这还是 beta，原文也提醒边界可能变化。

能拿来做什么

• 如果你用 Claude Code 发起长时间构建或检查，先确认服务器是否支持 MCP task，再明确设置等待策略，并把远程服务与 stdio 服务的退出行为写进使用说明。
• 如果你维护 claude -p 自动化流程，检查每个 MCP 工具是否可能请求输入，并为取消、部分完成和失败退出定义处理方式。
• 如果你用 Node 编写 MCP server，按每次 tools/call 的能力声明决定是否返回任务，同时明确记录断线、进程退出和取消请求的处理规则。
• 如果任务完成后允许 Claude 继续操作文件或调用工具，检查对应的 deny rules，并验证恢复任务后实际触发了哪些动作。