以语音还是键盘的方式给 LLM Agent 下指令看似只是交互习惯差异但背后其实藏着输入链路、噪声分布、Token 语义衰减等一系列工程问题。本文从输入扰动这一系统化角度出发拆解语音输入与键盘输入在 LLM Agent 场景下的差异、影响机制和缓解方案并提供一套可用于评测和增强鲁棒性的 Python 示例帮助你判断你的 Agent 到底更适合“打字”还是“说话”。1. 背景与核心概念1.1 LLM Agent 输入方式正在从单一走向多元大语言模型LLMAgent 的核心价值在于把用户的自然语言指令转化为具体的工具调用、API 请求、代码执行或信息检索动作。过去我们与 Agent 的交互几乎是清一色的键盘输入在对话框里打字然后等待模型回应。随着语音助手、车载场景、智能眼镜等终端形态的普及“对 Agent 说话”已经成为越来越常见的交互方式。但这里有一个经常被忽略的问题键盘输入和语音输入到达 LLM 的“文本”维度上并不是等价的。键盘输入直接生成文本语音输入则需要经过语音识别ASR这一道桥梁。两道不同的链路会引入完全不同的扰动Perturbations这些扰动会直接影响 Agent 对用户意图的理解和执行效果。所以当我们讨论“Should We Type or Talk to LLM Agents”时真正要回答的并不是哪个方式更先进而是在以扰动为变量的评测体系下这两种输入方式各自的表现如何以及我们应该如何让 Agent 对它们都保持稳定。1.2 输入扰动是什么输入扰动指的是从用户产生原始意图到 LLM 真正接收到指令文本之间所有可能对文本质量造成干扰的因素。它并不局限于网络抖动或音频噪声而是包括语音转写文本中的同音错字。键盘打字时的丢字、拼音输入法误选候选词。自动纠错Auto-Correct对原本正确语句的改写。断句失败导致的长句截断。口语化表达与书面表达在标点、语气词上的差异。这些扰动通常不会被普通用户注意到因为它们在小模型或人工阅读时往往可以通过上下文语义被自动纠正。但 LLM Agent 的执行链路中指令文本往往会先被解析为 JSON、意图标签或参数槽位扰动可能在这一阶段直接被放大。1.3 为什么研究扰动对 Agent 尤其重要一个纯聊天型的 LLM 面对“帮我查下明天北京到上海的高铁”和“帮我查下明天北京到上岗的高铁”大概率仍然能结合常识推断出正确意图。但 Agent 不同它必须把这句话转换成语义参数{ from_city: 北京, to_city: 上海, date: 2025-06-10 }一旦 ASR 把“上海”识别成“上岗”而 Agent 的解析逻辑又强依赖于命名实体识别那么这个微小扰动就可能导致车次查询失败甚至返回一个不存在的目的地。从这个意义上说输入扰动对 Agent 的危害远大于对纯聊天模型的影响。这也是“输入扰动”被当作研究主题来系统化分析的根本原因。2. 语音输入与键盘输入的链路差异2.1 键盘输入链路键盘输入是从用户认知到屏幕文本的最直接链路大致可以表示为用户意图 - 候选组词/拼写 - 文本 - LLM Agent在这个链路中扰动主要来自用户自身的拼写错误尤其是英文环境。输入法候选词误选。中英文输入法切换导致的全半角符号错误。语音输入法的部分残留比如手机上“边说边打字”模式。键盘输入的扰动密度通常较低而且错误模式比较集中。比如“Beijing”输成“Beijng”人眼几乎可以无痛纠正。但需要注意的是键盘输入的错误通常是独立的不太会像语音识别那样产生整句的语义漂移。2.2 语音输入链路语音输入链路的环节要长得多用户意图 - 发声 - 麦克风采集 - 音频信号 - ASR声学模型 - 语言模型解码 - 文本 - LLM Agent每一个环节都有引入扰动的可能。麦克风采样率不足会导致部分音素畸变环境噪声会掩盖语音端点ASR 解码时又可能因为语言模型偏置而选择了一个高频但错误的候选文本。最终进入 LLM 的文本往往已经混入同音字、多音字错误、语气词、重复词甚至整段漏识别。2.3 两条链路对 Agent 的不同影响从 Agent 解析的角度看两条链路带来的问题性质完全不同。键盘输入的错误更接近“字符级扰动”。一个词被拼错影响的是命名实体识别的边界但句子结构和标点通常完整LLM 可以通过上下文利用自注意力机制捕捉到正确词元。语音输入的错误则更接近“语义级扰动”。ASR 输出的文本在字面上往往通顺且符合语法但关键实体被替换成了同音字。这导致 LLM 很难依靠语法线索识别出错误位置因为错误部分读起来完全自然。结合到 Agent 的真实场景可以总结为维度键盘输入语音输入错误来源拼写、输入法、键盘误触ASR 声学识别、语言模型解码错误粒度字符级词级/字级语义替换错误可感知性人眼易发现人眼不易发现对 Agent 参数解析的影响局部字段异常关键实体替换可能导致动作错误修复方式字符编辑距离匹配语义纠错、多候选融合3. 输入扰动的类型与影响机制3.1 语音输入常见扰动语音输入的扰动可以归纳为三类。第一类是替换型扰动。由于汉语同音字非常多ASR 语言模型有时会把目标词替换为相同发音的另一个词。例如“订明天九点的闹钟”被识别成“订明天酒点的闹钟”“酒点”是一个不存在的实体但“订...点”的句式仍然保留导致 Agent 解析出的时间槽位出错。第二类是插入型扰动。ASR 在口语场景中经常保留语气词比如“嗯”、“那个”、“就是说”。这些词在自然语言理解中被视为无害停顿但在 Agent 的槽位填充场景中如果直接拼接进目标文本会干扰到实体的匹配。第三类是截断型扰动。语音端点检测VAD把一句话误判为两句话或者网络传输丢包导致音频被截断都会让 ASR 只输出半句话。这时 LLM Agent 拿到的指令是残缺的没有任何上下文可以补救。3.2 键盘输入常见扰动键盘输入的扰动虽然多存在于字符层面但也不容忽视。一个典型场景是拼音输入法的模糊音问题。用户想说“查询”结果在输入法里选择了“插询”这种词在 ASR 场景里很难出现但在键盘输入里却常见。另一个场景是英文自动纠错很多移动端键盘会把用户刻意输入的命名实体改成“更常见”的词例如把 API 名或地名自动纠正成字典里的通用词。键盘输入还存在一种隐性问题符号和数字的输入错误。比如日期“6月10日”被误打成“6月1日”如果不是手动复核这种扰动是 Agent 端最头疼的类型因为它在语义上完全合法。3.3 扰动如何影响 Agent 的决策链路要理解扰动的影响机制需要把 Agent 的处理流程拆开来看文本输入 - 意图识别 - 实体抽取 - 动作选择 - 工具调用 - 结果返回一般直觉认为意图识别是第一个环节如果文本出现扰动应该在这里就出问题。但实际上BERT 时代的意图识别模型对局部噪声有较强的容忍度尤其是在短句场景下。真正容易出错的是实体抽取和参数映射环节。举例来说用户对订票 Agent 说“我要买明天从杭州去北京的票。”如果 ASR 将“北京”转写为“背景”意图识别模型仍然大概率判定为“订票”但实体抽取阶段给出的出发地、目的地列表里“背景”无法匹配到城市数据库Agent 就会陷入两种错误状态返回“未找到目的地”要求用户重新输入。错误地选择了另一个名字相近的城市导致票务逻辑执行到了错误的业务分支。第二种情况的危害更大因为它不会立即报错而是等到出票完成、支付成功之后用户才发现目的地不对。这正是输入扰动对 Agent 系统最大的威胁不是“无法理解”而是“错误理解并执行”。4. 实验设计思路与评测方案4.1 评测目标无偏对比两种输入方式研究“Typing vs Talking”之前首先要确定一个可量化的评测目标。基于扰动分析的逻辑可以用以下四个指标来对比指令完成率Agent 最终是否成功执行了用户意图。参数准确率从指令中提取的槽位值是否与真实值完全一致。平均修复轮数用户需要额外补充多少次信息才能纠正 Agent。严重错误率Agent 未报错但执行了错误动作的比例。这四个指标之间存在优先级。实际场景中严重错误率是最需要警惕的因为它意味着系统在没有用户确认的情况下执行了错误操作。4.2 构造输入扰动数据集无偏对比的关键在于构造同一批“原始意图”在两种输入扰动下的对应指令。由于我们关注的是最终进入 LLM 的文本质量所以不需要真实录音和真实键盘设备只需要针对原始意图做扰动注入。下面用 Python 模拟两种扰动。先看键盘输入扰动主要模拟键盘相邻字符替换import random adjacent_keys { a: [s, q, z], b: [g, h, v, n], c: [d, f, x, v], d: [e, r, s, f], e: [r, w, s, d], f: [g, t, r, d], g: [h, y, u, f, v], h: [g, j, y, b, n], i: [o, u, k, j], j: [k, h, u, i], k: [l, j, o, i], l: [o, p, k], m: [n, j, k], n: [b, m, h, j], o: [p, i, k, l], p: [o, l], q: [w, a, s], r: [t, e, d, f], s: [d, w, e, a, x], t: [y, r, f, g], u: [y, i, h, j], v: [c, b, f, g], w: [e, q, s, a], x: [z, s, c, d], y: [t, u, g, h], z: [x, a, s] } def keyboard_noise(text, error_rate0.05): chars [] for ch in text.lower(): if ch in adjacent_keys and random.random() error_rate: chars.append(random.choice(adjacent_keys[ch])) else: chars.append(ch) return .join(chars)接着模拟语音输入的同类词替换。对于中文场景可以引入一个简单的同音字词典same_pronunciation { 北京: [背景, 背静], 上海: [上岗, 上航], 明天: [名天, 明添], 酒店: [酒点, 灸点], 查询: [察询, 茶寻], 余额: [鱼鹅, 于额] } def asr_noise(text, error_rate0.15): for word, candidates in same_pronunciation.items(): if word in text and random.random() error_rate: text text.replace(word, random.choice(candidates)) return text这两段代码分别刻画了两种典型逻辑键盘输入倾向于破坏字符串的局部连续性语音输入则是替换整个语义单位。后续评测时可以让一个 Agent 分别处理同一批原始意图、键盘扰动文本、ASR 扰动文本再统计指标。4.3 评测流程一个规范的无偏评测流程应该包含以下步骤准备原始意图集每条意图包含期望动作与槽位真值。对每条意图分别生成键盘扰动版本和 ASR 扰动版本。将三个版本的指令分别发送给 Agent。收集 Agent 的动作输出、参数输出和最终执行结果。与槽位真值比对统计四类指标。对指标差异进行显著性分析。4.4 预期结论与解读在扰动率相同的条件下通常会发现语音输入的严重错误率高于键盘输入。原因是键盘错误更容易通过字符级特征被 LLM 识别并隐式纠正而 ASR 同音替换具有“伪装成正确文本”的能力。但这里要提醒一点这里的结论依赖于使用的 ASR 引擎和输入法。不同 ASR 引擎对口语场景的建模能力差别很大切不可把一次实验的结果当作绝对结论。5. 工程实践增强 LLM Agent 对输入扰动的鲁棒性既然两种输入扰动无法完全避免那么就需要在 Agent 侧做鲁棒性增强。下面给出几个可以落地的方法与代码示例。5.1 方法一槽位值白名单归一化对于目的地、日期、时间这类可以枚举的槽位值可以不做实体抽取而是先用归一化模块做预匹配。当 ASR 输出“背景”时把它映射到候选城市列表中的“北京”。city_alias { 背景: 北京, 上岗: 上海, 广洲: 广州, 身圳: 深圳, 杭洲: 杭州 } def normalize_city(input_text): for alias, standard in city_alias.items(): if alias in input_text: input_text input_text.replace(alias, standard) return input_text这是最简单的一层防护适合地名、人名、酒店名这种强约束实体。它的优点是成本低缺点是依赖人工维护别名表。5.2 方法二多候选输入融合ASR 通常可以返回 Top-N 候选结果而不是只有一条转写文本。如果 Agent 接口支持传入多段候选文本就可以用投票或打分机制取最合理的组合。candidates [ 帮我订明天去背景的机票, 帮我订明天去北京的机票, 帮我订明天去背静的机票 ] def choose_best_candidate(candidates): # 思路计算每个候选与槽位词表的编辑距离取综合距离最小的候选 import difflib valid_cities [北京, 上海, 广州, 深圳, 杭州] best_score float(inf) best_text candidates[0] for text in candidates: score 0 for city in valid_cities: # 如果候选文本包含某个城市则只计算该词的匹配成本 if city in text: score 0 else: # 未匹配到任何标准城市给一个较大惩罚 score 2 # 还可以加入文本长度惩罚、历史交互上下文打分 if score best_score: best_score score best_text text return best_text final_text choose_best_candidate(candidates) print(final_text)这段代码展示的是“纠错打分”的思路。真实工程中候选打分应该同时考虑 ASR 置信度、词表匹配度、上下文一致性和历史偏好权重可以手工配置也可以通过小样本学习得到。5.3 方法三让 LLM Agent 具备“疑问确认”机制与其让 Agent 静默接受一个低置信度参数不如让它显式地输出识别结果供用户确认。这个机制在“严重错误率”指标上非常有效。def agent_with_confirm(parse_result, confidence): # parse_result 为解析出的动作参数confidence 为该参数的置信度 if confidence 0.6: return { action: ask_user, message: f我识别到您要订票目的地是 {parse_result[to_city]}请问对吗 } return { action: execute, params: parse_result } result agent_with_confirm({to_city: 背景}, 0.45) print(result)这种方法虽然会增加一轮交互但在语音输入场景下是值得的。用户顶多多说一句“对”但可以避免一次完全错误的交易动作。5.4 方法四Prompt 级别的输入规范化提示对于基于 LLM 的 Agent可以在 System Prompt 中加入一条规范化指令要求模型把 ASR 文本中的同音字先映射到合理实体再进行参数解析。这种做法在工程上最容易实施但效果不稳定需要反复调试提示词。你是工具调用助手。用户指令可能来自语音识别存在同音错字。 在解析参数前先根据常识把明显同音的地名、时间、人名映射为正确值 然后才输出 JSON 参数。通常这条提示词适合放在 Agent 的“意图理解 槽位填充”专用提示模板中而不是通用对话模板中避免影响多轮闲聊能力。6. 常见问题与排查思路下面把语音和键盘输入场景中Agent 开发容易遇到的高频问题整理成表格方便定位排查。问题现象可能原因解决思路语音输入后 Agent 返回“未找到目的地”ASR 将地名转写为同音字增加槽位别名表或引入候选文本融合键盘输入后 Agent 执行了错误动作用户选词错误或自动纠错改写对关键动作增加用户确认机制语音指令在长句时频繁截断VAD 断句策略与 ASR 模型不匹配调整端点检测阈值或使用标点预测模型合并短句同一句话在不同时间输入结果不同ASR 引擎版本更新或热词表未生效固定 ASR 模型版本确认热词权重配置中文输入法导致英文符号被转换全半角混淆在 Agent 入口做全角转半角预处理多轮对话中语音指令指代无法解析指代消解依赖前文但 ASR 输出丢失了标点在 Prompt 中要求模型结合历史消息解析键盘输入中相邻键误触较频繁手机端触摸键盘本身误差大Agent 侧启用编辑距离模糊匹配在这些问题中最值得优先处理的是“语音输入后返回未找到目的地”和“键盘输入后执行了错误动作”。它们分别对应低置信度拒绝和静默错误两个极端前者影响用户体验后者影响系统安全。7. 最佳实践与工程建议7.1 根据业务场景选择默认输入方式不是所有 Agent 都应该同时开放语音和键盘输入。在噪音较大的户外环境语音识别错误率会急剧上升此时产品默认入口应该保持键盘输入而在车载、智能家居等不方便打字的场景语音又是唯一合理选项。建议从业务场景的“容错空间”出发做决策涉及支付、删除、发送等不可逆操作时即使默认使用语音输入也必须引入确认机制而查询类、闲聊类操作可以放开语音输入减少交互成本。7.2 建立扰动驱动的评测回归集Agent 上线后不能只靠真实用户流量来发现扰动问题。应该建立一份带扰动的回归评测集包含不同口音、不同环境噪声、不同输入法候选词错误。每次升级 ASR 模型或 Agent 解析逻辑时先跑一遍这份评测集对比各指标变化。具体做法可以很简单把第 4 节里的扰动生成代码接入现有的 pytest 或 CI 流程作为单测之一。以下是一个最小示例def test_agent_city_parsing_with_asr_noise(): original 帮我买明天从杭州去北京的机票 noisy asr_noise(original, error_rate1.0) # 强制替换 assert noisy ! original result agent_execute_with_real_api(noisy) assert result[to_city] 北京, f扰动 {noisy} 解析失败注意这里的agent_execute_with_real_api需要是对真实 Agent 的调用而不是 mock 结果否则无法起到回归保护作用。7.3 记录输入元数据便于问题复盘生产环境中要尽量保留每条指令的输入元数据例如输入方式键盘 / 语音。ASR 置信度如果有。WER 估计值。用户是在几轮对话后说出的这条指令。Agent 最终执行的动作。当线上出现“用户说 AAgent 却执行了 B”的投诉时这些元数据可以帮我们快速定位是语音识别环节出错还是意图解析环节出错从而把修复对象聚焦在正确的模块上。7.4 注重安全边界输入扰动不只是可用性问题还可能带来安全风险。例如攻击者利用同形字符、谐音词绕过关键词过滤或者利用语音输入中的相似发音触发 Agent 的高权限操作。工程上应当为 Agent 的工具调用增加权限边界调用删除、转账、发送请求等动作时必须要求置信度分数高于阈值并且对高敏感操作要求用户二次确认。7.5 不要盲目追求低 WER很多团队会陷入一个误区认为只要把 ASR 词错误率WER降下来Agent 的识别效果就一定会好。实际情况是Agent 解析任务对“关键实体错误”的敏感度远高于“通用词错误”。哪怕整句 WER 在 5% 以内只要地名、数字、日期中的一个被替换任务就可能失败反过来即使 WER 较高但如果错误集中出现在语气词和连接词上Agent 仍然能正确执行。所以评估语音接入 Agent 的效果时应该以任务级准确率为核心指标而不是只盯着 ASR 的 WER。把 ASR 词错误和 Agent 任务执行之间的因果链路建立起来比单纯优化声学模型更有效。8. 总结与后续方向回到最初的问题应该打字还是说话与 LLM Agent 交互本文给出的答案是两者没有绝对优劣差别在于扰动类型和错误传播路径。键盘输入的扰动偏向字符级错误可预期性强语音输入的扰动偏向语义级更隐蔽也更容易导致 Agent 静默执行错误动作。研究输入扰动的最终目的不是为了消灭某个输入方式而是让 Agent 在两种输入方式下都能保持足够高的意图还原能力。后续可以从以下几个方向继续深入在真实 ASR 引擎与真实输入法上组件更大规模的扰动词表并量化不同模型版本对任务级准确率的影响。把输入扰动引入 RAG 场景观察检索环节对实体扰动的容忍度。面向 Agent 评测Evals设计更合理的输入扰动注入规则让评测集更接近真实使用环境。在模型侧尝试声学特征到语义标签的端到端映射跳过文本中间态的扰动。如果你正在开发自己的 LLM Agent 产品建议先从记录输入方式和 ASR 置信度入手用一周的真实流量数据做一次扰动分布分析再决定优先优化哪一端。这样比直接换更大参数的 ASR 模型更能带来可感知的产品体验提升。