[从 Windows 7 开始，Microsoft代理已弃用，在后续版本的 Windows 中可能不可用。
与任何设计良好的接口一样，交互式过程应尽量减少导致错误的情况。 但是，很少可能消除所有错误，因此支持良好的错误恢复对于保持用户的信心和兴趣至关重要。 通常，错误恢复涉及检测错误、确定原因和定义解决错误的方法。 用户更好地响应协作界面，与用户合作完成任务。
语音错误恢复的第一步是检测故障条件。 语音识别可能因各种错误而失败。 错误条件通常是由于输入无效、显式用户更正或取消或用户重复而检测到的。
当识别引擎与用户所说的内容不匹配时，会发生 拒绝错误。 后台噪音或早期启动也是识别失败的常见原因，因此要求用户重复命令通常是一个很好的初始解决方案。 但是，如果短语不在当前活动语法之外，则要求用户重新表述请求可能会解决问题。 措辞的差异可能会导致与当前语法中的某个内容匹配。 列出或建议适当的预期输入选项是另一种替代方法。
拒绝错误恢复的良好策略是将这些技术组合在一起，使用户重新走上正轨，如果失败仍然存在，则提供越来越多的帮助。 例如，可以通过“Huh？”或“What？”或手到耳手势等审讯来响应初始失败。 短响应会增加用户重复语句不会失败的可能性，因为用户说得太快。 重复失败后，后续请求重新分配可提高匹配给定语法中某些内容的机会。 在此处，提供接受的命令的显式提示会进一步增加匹配的可能性。 以下示例演示了此方法：
用户：我喜欢一个芝加哥风格的比萨饼与凤尾鱼。
字符： （手到耳） 胡？
用户：我希望有一个芝加哥比萨饼与鱼。
字符：（摇头）请重新描述你的请求。
用户：我说芝加哥披萨，有鱼。
字符： （耸耸） 对不起。 告诉我你想要的披萨风格。
用户：芝加哥，有鱼。
性格：还是没运气。 以下是你可以说的：“芝加哥”、“夏威夷人”或“组合”。
若要使错误处理感觉更自然，请确保在响应错误时提供一定程度的随机变化。 此外，对重复响应的任何请求的自然用户反应是夸大或增加重复语句时的音量。 有时提醒用户正常和清楚地说话可能很有用，因为夸大或增加的音量可能会使语音引擎更难识别单词。
渐进式帮助应多于引起用户注意的错误;它应指导用户通过连续提供更丰富的信息性消息来指导用户讲当前语法。 似乎试图理解的接口鼓励用户高度的满意度和容忍度。
替换错误（其中语音引擎识别输入但与错误的命令匹配）更难解决，因为语音引擎检测到匹配的话语。 当语音引擎将多余的声音解释为有效输入（也称为 插入错误）时，也可能发生不匹配。 在这些情况下，需要用户帮助来确定错误条件。 为此，可以重复语音引擎返回的内容，并要求用户在继续作之前进行确认：
用户：我喜欢芝加哥风格的比萨饼。
角色： 你说你想吃一个“芝加哥风格的披萨”吗？
用户：是。
性格：你喜欢什么额外的成分？
用户：凤尾鱼。
角色：你说“鱼”吗？
用户：是。
但是，将此方法用于每个言语都变得效率低下且令人厌烦。 若要解决此问题，请限制对产生重大负面影响或增加直接任务复杂性的情况进行确认。 如果用户很容易做出或反向更改，则可以避免请求确认其选择。 同样，如果做出选择可见，则可能需要提供显式更正。 例如，从列表中选择项可能不需要验证，因为用户可以查看结果并轻松更改它们。 还可以使用置信度和备用分数来提供确认阈值。 可以通过在给定情况下保留用户作的历史记录并基于一致的用户确认消除验证来调整阈值。 最后，考虑接口的多模式性质。 鼠标或键盘的确认也可能合适。
仔细选择确认的措辞。 例如，“你说...？” 或“我想你说...”比“你真的想...？”好，因为前短语暗示正在查询字符的侦听（识别）的准确性，而不是用户可能错觉了。
另请考虑响应的语法。 例如，负响应可能会生成拒绝错误，需要额外的提示，如以下示例所示：
用户：我喜欢一些辣椒。
性格：你说“没有火腿”吗？
用户：不，我说辣椒。
字符： 嗯？
用户：佩波尼。
修改语法以包含前缀来处理自然响应变体会增加恢复过程的效率，尤其是在用户未确认验证提示时。 在此示例中，确认可以通过修改“辣椒”的语法，在一个步骤中进行处理，包括“没有我说辣椒”、“我说辣椒”和“没有胡椒粉”。
还可以使用语音引擎返回的替代匹配项作为纠正确认来处理替换错误：
用户：我喜欢一些辣椒。
角色： （听到 “没有火腿” 作为最佳匹配， “辣椒” 作为第一种替代） 你说 “没有火腿” 吗？
用户：不，辣椒。
角色： （仍然听到 “没有火腿” 作为最佳匹配， 但现在提供第一种替代） “佩波尼” ？
同样，可以保留常见替换错误的历史记录，如果特定错误频繁，则首次提供替代项。
在任何识别错误情况下，请避免指责用户。 如果字符建议甚至暗示用户要归咎，或者该字符似乎对错误无动于衷，则用户可能会受到冒犯。 在这里，还仔细选择明确接受责任的措辞，适合情况，并使用各种方式创造更自然的回应。 在表达道歉时，请避免将“oops”或“uh-oh”等模棱两可的话解释为指责用户。 请改用“对不起”或“我的错误”等短语。反复或更严重的错误可能会使用更详细的道歉，例如“我真的对此感到抱歉”。在确定响应类型时，还要考虑字符的个性。 另一种选择是指责外部情况。 评论，如，“男孩，它吵闹在那里”，把责任从用户和角色带走。 提醒用户交互的合作性质可能也很有帮助：考虑短语，例如，“让我们看看我们可以做些什么来完成这项工作。
Microsoft代理还支持一些用于识别的自动反馈。 检测到言语时，“侦听提示”将显示听到的最佳匹配项的语音文本。 可以根据定义的命令的置信度设置来设置自己的文本以显示。
由于存在错误潜力，始终需要确认任何产生严重负面影响且不可逆的选择。 当然，你需要在作结果可能具有破坏性时需要确认。 但是，考虑还需要确认中止任何漫长的过程或作的情况。