一句话定义：Elicitation（向用户追问）是 MCP（Model Context Protocol，AI 词典：模型上下文协议">模型上下文协议）里的一种交互机制——服务器在执行工具的过程中，可以主动通过客户端向用户提问、补齐缺失的信息，拿到回答后继续执行，而不是直接报错收场。
它为什么存在
MCP 解决的是“AI 应用（客户端）如何连接外部能力（服务器）”的问题。常规流程是单向的：模型决定调用某个工具，客户端把参数发给服务器，服务器执行并返回结果。
麻烦在于，模型给的参数常常是猜的。让它订会议室，它不知道要哪一间；让它查订单，它不知道用哪个账号。过去的做法只有一条路——服务器报错“参数不全”，模型看到错误再猜一轮，用户在这场来回里完全缺席，最后只看到一句“执行失败，请提供更多信息”。
Elicitation 把这条单向路改成双向：服务器发现缺东西，就发一个追问请求，客户端用自己的界面（对话框、表单、确认弹窗）呈现给用户，用户填写或拒绝，答案回到服务器，工具接着往下跑。
打个比方
去政务大厅办事，材料少了一页。最差的体验是窗口把材料一推：“下次带齐再来。”好一点的体验是窗口人员抬头问一句：“身份证带了吗？给我看一下。”你递过去，事情接着办。
这里的分工很关键：问什么由窗口（服务器）决定，怎么问、要不要替你问由大厅（客户端）决定，答不答由你决定。三个角色各管一段，谁也不越界。
几个容易混的概念
| 机制 | 方向 | 人在不在环里 | 干什么 |
|---|---|---|---|
| Tool Call（工具调用） | 模型 → 服务器 | 否 | 交代任务、拿结果 |
| Elicitation（向用户追问） | 服务器 → 用户 → 服务器 | 是 | 执行中途补信息、做确认 |
| Sampling（采样） | 服务器 → 客户端的模型 | 否 | 借宿主的模型生成一段内容 |
| 报错返回 | 服务器 → 模型 | 否 | 把问题抛回去让模型自己重试 |
| 传统配置页 | 事先一次性填完 | 是 | 与本次调用无关的静态设置 |
最实质的区别在最后两行：报错返回是把球踢给模型，让它猜着重来；Elicitation 是把球递给真正知道答案的人。
两个值得注意的边界
一，用户可以不答。客户端有权不展示、用户有权拒绝或取消，服务器必须能处理“没问到答案”的情况，而不是卡在那里。所以它适合少量、扁平、简单的补充字段，不适合拿来做复杂表单。
二，它也是“危险操作确认”的天然位置。删数据、发邮件、扣款这类动作，与其在提示词里反复叮嘱模型“先问用户”，不如让服务器在协议层面直接发起一次追问。具体支持哪些字段和能力，以官方规范页面为准。
对两类人的意义
对开发者：少写一堆“参数不全请重试”的分支，把校验和追问变成一条正常路径，而不是异常路径。
对普通使用者：AI 助手不再动不动就“失败”，而是当场问你一句；真要动你的东西之前，它会先停下来。