Appearance
一次 MCP 交互为什么可能多轮：MRTR、Elicitation 与 Extensions
前置：MCP 谁可以调用什么：Authorization、OAuth 与 Enterprise Managed Auth
核心问题：一次 MCP 请求需要多轮询问用户或扩展交互时，谁保存中间状态，怎样防止协议交互越过 Harness 的控制边界？
创建工单时缺少 project id，Server 可以明确返回还需要什么输入；Host 收集用户补充后继续，而不是把“等待用户”绑在某条 HTTP 连接或进程内存里。多轮是 请求语义上的状态推进，不是把旧式长连接 session 重新包装回来。
Multi Round-Trip Requests (MRTR)
普通 RPC 假设一次 request 很快得到一次 response；MRTR 允许同一个逻辑请求在完成前暂停并要求额外信息。
例如 Tool 想创建生产资源，但还缺 region：
text
Host → tools/call
Server → input_required(region)
Host 收集用户输入 / 做 policy check
Host → continuation request(region=...)
Server → final result它解决的是协议层的“请求尚未完成，需要补输入”，不是 Agent 自己决定再思考一轮。Host 仍然掌握用户交互、authorization 和是否继续请求的控制权。
Elicitation / input_required
Elicitation 是 MRTR 的具体用户输入场景：server 明确描述缺少什么，Host 决定如何向用户/上层系统收集并再次调用。Host 必须保留 approval/security 边界，不能把 server 请求直接当高权限用户指令。
它是协议化的等待/输入边界，不应被当普通 tool error 自动 retry。
Extensions Framework
Extensions Framework 允许非核心能力独立协商和演进。本文只建立“Core 不因新增能力而重新膨胀”的边界；长任务 Tasks Extension 的 durable handle、poll/cancel 与 Harness 映射在下一篇单独讲。
实现必须显式识别 extension support 和版本，未知扩展应可安全忽略/拒绝。
多轮协议交互和 Agent Loop 不是一回事
一个 MCP 操作在完成前可能需要额外往返，例如 Server 需要 Host 提供缺失输入或触发用户交互。此时可以把控制过程理解为：
text
Runtime invokes MCP capability
↓
MCP interaction needs more input
↓
Host handles protocol-level round trip / elicitation
↓
result becomes Tool observation
↓
Agent Loop continues关键边界是：协议内部多一次 round trip，不等于 Agent 自动多做了一轮推理。 Runtime 仍然掌握 Run 状态；如果交互需要等待用户数小时，则应转成 durable wait/approval，而不是让一个 HTTP coroutine 永久挂住。
Extensions 也应当通过 capability detection 明确启用。不要因为某个 Server 实现了扩展，就让核心 Runtime 直接依赖扩展专有对象；通过 MCP Adapter 把它收敛成内部统一状态和事件。
Failure Modes
把 MRTR 实现成长生命周期 Transport Session
症状： Server 依赖同一进程/连接保存中间状态，连接断开后无法继续。
处理： 每轮请求自描述；需要持久化的 task/input state 放 durable store，并通过明确 identity 继续。
自测
- 一次 MCP 调用中 Server 还需要向用户补充询问信息。为什么这种交互不能简单假设为单 request/response？
- Elicitation 产生的新用户输入进入 Harness 后，应以什么 authority 重新参与后续决策？