自动化卡住，有时只差一个没有问过的问题
假设员工请智能体安排一项内部培训，时间和主题都有了，但没有说明线上还是线下。系统若自行选择线上，可能违背真实安排；若把整个任务退回，又浪费已经完成的整理。更好的处理应取决于这项信息是否影响下一步动作，以及是否存在明确的企业默认规则。
MCP 2025-11-25版规范提供 Elicitation 机制，允许服务端通过客户端向用户请求补充信息，并区分表单模式和外部网址模式。它提供的是交互协议，并不会自动替企业决定哪些问题该问、问谁或答复后能执行什么。
本文讨论既有规范的企业应用，不是新版本发布报道。实际工具是否支持相应模式，需要检查客户端与服务端实现。不能因为产品宣称兼容 MCP，就推断它支持协议里的每一种交互能力。
缺失字段先分清能否由规则确定
并非每项空缺都需要打断用户。若部门已经明确规定内部培训默认使用某种会议方式，且用户请求没有与其冲突，系统可以依规则准备。但应能说明采用了哪条规则，不能把模型习惯写成企业约定。
真正需要补问的，是会改变业务结果又缺乏可靠依据的输入。培训方式影响会场与链接，费用归属影响后续审批，联系人选择影响通知对象。这些字段不能仅凭语气猜测。问题应聚焦当前阻塞点，尽量让用户一次就理解为何需要回答。
可以把缺项分成“有明确默认”“需要本人决定”“需要其他岗位确认”三组。这是本文建议的业务整理方法，不是协议定义的固定分类。它的作用是防止系统把所有责任都推给发起人，也防止模型擅自承担不属于它的决定。
一张小表单，也要让用户知道信息交给谁
规范要求客户端清楚展示请求信息的服务端，并允许用户拒绝或取消。在企业界面里，员工需要看懂的还包括用途：是补充一个地点供系统查空闲，还是确认一项安排供后续执行。若目的不同，提示文案也应不同。
表单中只放这一步真正需要的字段。例如选择培训地点，不必顺手索取完整人员资料。字段旁可以解释格式和影响，避免用户为了推进任务随便填一个值。输入校验解决格式问题，业务确认解决选择是否合适，二者不能混在一起。
对敏感凭据，规范禁止通过表单模式索取密码、API 密钥、访问令牌等信息，涉及这类交互应使用对应的网址模式。这项边界不能被“方便调试”替代。企业还需核对目标域名和实际授权范围，不能把任意外链都当成可信入口。
拒绝与取消，应有各自可理解的后续
用户拒绝提供信息，可能表示不愿分享，也可能认为系统根本不需要它；取消则可能只是暂时离开。系统若把两者统一当成“空值”，后续又自动补上默认值，就等于绕过了用户的表达。
可以在业务流程中写清楚：拒绝时保留已经完成的草稿，并说明无法继续哪一步；取消时结束当前交互，允许以后从合适位置接续。若业务要求不能保留草稿，也应提前说明。具体行为由任务风险和企业规则决定，没有一种适合所有流程的通用答案。
超时也不能被解释成同意。对必须确认的选择，等待结束之后应进入清楚的待处理状态。若任务有时效，需让发起人知道什么时候过期、怎样重新发起。这些状态应能从界面或任务记录查到，而不是只在技术日志里出现。
回答一个问题，不等于授权全部后续动作
员工选择了会议地点，只能说明地点确定了，不能自动扩大为允许发送所有邀请。表单确认的对象应与后续动作逐项对上，尤其是会影响外部收件人、费用或业务记录的操作。
例如界面可以先展示准备结果，再依据已有授权执行，或者明确要求用户确认最终安排。具体采用哪种方式取决于用户已经授予的权限与任务范围。重点是保留可核对的关系，而不是每一步都机械弹窗。
企业还应检查，交互返回之后业务对象有没有变化。会议时间被其他人修改，或原地点已不可用，都可能让刚才的回答失去适用条件。遇到这种情况，应解释变化并重新处理必要信息，不能只因为拿到一个合法字段就强行推进。
用三种不配合的回答检验交互质量
验收时，除了正常填写，还可以测试拒绝、取消和无效值。检查任务是否进入预定状态、是否保留了合理的进度、有没有发生用户未授权的动作。若拒绝后仍继续执行，说明问题不在文案，而在流程分支。
还应测试客户端不支持所需交互模式的情况。规范能力需要双方声明与配合，产品应有可理解的提示，而不是把协议错误原样丢给业务用户。本文没有对某一实际账号做兼容性测试，因此不会声称所有常用客户端已经支持这些行为。
建议保存一张简短验收表：缺什么、谁能回答、问法是什么、接受和拒绝后各走哪里、对应业务对象是哪一个。这样业务负责人可以检查决定权，工程人员可以检查状态，最终用户也能理解为什么被打断。
先把一个高频缺项处理好
可以从内部最常见的一项缺失信息开始，例如会议方式、报表范围或通知对象。观察员工是否能快速理解并准确补充，再决定是否推广到其他任务。不要一次设计一份涵盖所有情况的大表单，把智能体变成另一套繁琐录入系统。
一路凯歌建议，让智能体追问的目标是缩小必要的不确定性。能按真实规则确定的就说明规则，需要人的决定就把问题问清，用户不愿继续时就尊重其选择。协议提供传递方式，企业真正需要交付的是一条完整且可理解的交互路径。
要点总结
- 不能直接推断。需要核对客户端和服务端声明的能力及实际实现。
- 该版规范禁止用表单模式索取此类敏感凭据，需使用对应的网址模式并核对目标与范围。
- 需要确认的业务选择不能用超时代替同意，应按约定进入待处理或过期状态。
参考来源说明
本文为实用解读。来源时间：规范版本日期2025-11-25；页面发布日期未单列。2026-10-23核验。官方事实与本站建议分开表述；示例为假设场景，不代表客户案例、效果或实际账号测试。