Appearance
MCP Core 之外怎样扩展长任务和 UI：Tasks Extension 与 Apps
前置：一次 MCP 交互为什么可能多轮：MRTR、Elicitation 与 Extensions
核心问题：MCP Tasks/Apps 提供长任务或 UI 扩展后，Harness 应怎样接入而不重复建立第二套 Run 状态机？
版本说明（2026-08-24）：MCP
2026-07-28Core 已正式发布；Tasks 已移出实验 Core，作为io.modelcontextprotocol/tasksExtension 演进，但当前 Tasks specification 页面仍标记为 Draft。因此 Harness 必须做 capability negotiation，不能把 Tasks 当成所有 MCP Server 都稳定支持的 Core 能力。
先分清：MCP Task 不是 Harness Run
远程 MCP Tool 可能需要十分钟完成。Host 不应该为了等待它一直占住一个短 HTTP request；Server 可以通过 Tasks Extension 返回 durable task handle，客户端之后查询结果。
但内部概念不要混淆：
text
Shadow Harness Run / Node
│
└─ calls MCP Tool
│
└─ remote MCP TaskMCP task_id 是远端协议对象；run_id/node_id/operation_id 是 Harness 自己的执行事实。Adapter 负责建立映射，不能直接把协议对象当 Domain State。
Tasks Extension 解决“远端请求的异步生命周期”
在当前 2026-07-28 生态里，Tasks 是独立 extension 能力，不应假设每个 Server 都支持。客户端按请求声明扩展能力，Server 才可以把 tools/call 物化成 Task。
Task 至少需要让客户端理解：
text
task_id
status
poll interval / next check
input_required (如果有)
final result or error一个重要工程约束是：Server 返回 task handle 前，Task 必须已经 durable created。 否则客户端拿到 task_id 后立刻查询却找不到，会产生 task creation race。
Host 如何把远端 Task 接进自己的 Durable Wait
推荐映射：
text
ToolExecution(operation_id)
→ MCP tools/call
→ remote task_id
→ persist adapter binding
→ local Node enters WAITING_EXTERNAL
→ poll / subscription / external wake event
→ fetch final MCP result
→ normalize ToolResult
→ local Runtime continues本地 worker 不需要睡着等待。remote task_id + server identity + auth binding 应持久化到 Tool execution/wait record，之后由新的进程也能继续查询。
Cancellation 也是两层：
text
cancel local Run
→ mark local cancellation intent
→ adapter sends remote tasks/cancel when supported
→ remote cancellation is cooperative
→ local Runtime still verifies terminal fact不能因为远端接受 cancel request 就假定副作用一定没有发生。
Tasks 与 MRTR 的区别
MRTR 和 Tasks 都让“一次请求不必马上结束”，但等待尺度不同。
text
MRTR：一次逻辑请求中临时缺信息
call → input_required → 补输入 → 继续原请求
Task：工作需要跨更长时间存在
create task → later tasks/get → ... → completed例如 Tool 调用中缺一个用户确认，几轮交互就能补齐，适合 MRTR；如果工作需要几十分钟甚至跨连接持续存在，才更像 Task。
两者可以组合，但不要用 MRTR 的连接/调用上下文去“挂住”数小时任务，也不要为一次简单补参数创建长期 Task。
MCP Apps：UI 仍然是外部能力
MCP Apps 提供更丰富的交互/呈现能力，但 UI 内容来自外部 Server/extension，不能因为“能渲染”就获得更多权限。
Host 仍然负责：
- Server identity 与 extension capability；
- UI 可访问的数据范围；
- 用户操作是否转化成 Tool/approval command；
- credential 不进入不可信 UI；
- UI 与 Runtime state 之间通过显式 command/event contract 通信。
UI 不是 Runtime authority。 页面显示“部署成功”不能替代 ToolExecutionResult 或系统状态。
Failure Modes
默认所有 Server 都支持 Tasks
后果： 对不支持 extension 的 Server 产生协议耦合。
处理： capability/extension negotiation + normal tools/call fallback；真正的长任务需求不满足时显式拒绝或换路径。
用 MCP Task 取代本地 RunState
后果： 一个 Run 同时调用多个 Server、普通 Tool 和本地 Workspace 时无法形成统一 checkpoint/cancel/trace。
处理： MCP Task 只作为 Tool adapter 的 remote execution handle，映射进本地 Node/Tool execution record。
Task cancel = 副作用已取消
后果： 远端已经完成关键操作，本地却按未执行继续。
处理： cancellation 视为 intent；读取最终状态，必要时 reconciliation。
自测
- 一个需要后台运行十分钟的 MCP 操作，为什么不适合强塞进 Core 的同步调用语义？
- Tasks/Apps 扩展增加长任务或 UI 能力时，哪些 Runtime invariant 仍然应该由 Harness 自己维护？