前段时间在做 Agent 项目时遇到一个挺有意思的现象同一个任务用键盘把指令完整打出来Agent 能顺利执行换成语音讲一遍同样的需求Agent 要么听漏了一个关键条件要么把“北京”识别成了“背景”。一开始我以为是语音识别模型不够强后来对比了几组输入才发现问题不在识别准确率而在输入方式本身带来的“扰动”。这恰好也对应上了一个值得开发者认真对待的研究问题Should We Type or Talk to LLM Agents? 到底是该打字还是该说话不是产品交互层面的美观问题而是会直接决定 Agent 能不能准确理解任务、能不能稳定执行任务的技术问题。输入文本里的每一个错误、每一个口语词、每一次不规范的断句对 Agent 来说都是一种“输入扰动”。把这套扰动机制搞清楚比单纯争论“语音更自然还是键盘更高效”更有价值。1. 输入方式不是偏好问题而是扰动问题1.1 从一段“一句话指令”的差异说起假设你要让 Agent 帮你查一下“上周三上海办公室的会议记录”然后整理成摘要发邮件给项目组。键盘输入时你的文本是查一下上周三上海办公室的会议记录整理成摘要发邮件给项目组。这段文本干净、结构化有明确的动词、宾语、时间、地点和收件人。Agent 做意图识别和参数抽取时基本不会遇到障碍。改成语音输入时ASR自动语音识别先转写一遍。可能的结果是查一下上周三上海办公室的会议记录整理成摘要发邮件给项目组更常见的可能是查一下上周三上海办公室的“会议纪律”整理成摘要发给项目组。或者查一下上周三上海办公室的会议记录整理成摘要发邮件给项目组。这里出现了三类问题缺失标点整句话变成一个长串Agent 需要自己断句同音词误识别“记录”变成“纪律”语气词、重复词被吞掉或误插入。这些都属于输入扰动。它们不是 Agent 自身推理能力不够而是输入侧的噪声污染了 Agent 对任务的建模。1.2 输入扰动是如何影响 Agent 的LLM Agent 的工作链路通常可以拆成输入文本 → 意图识别 → 任务规划 → 工具调用 → 结果生成。键盘输入和语音输入在最前端就不一样后面每一步都会被前端的差异波及。从信息论的角度看输入扰动等于给原始信号叠加了噪声。语音输入的噪声更多来自 ASR 转写错误、口语化表达、断句缺失键盘输入的噪声则更多来自拼写错误、缩写、省略标点和复制粘贴带来的脏字符。两者方向不同但都会造成同一个后果Agent 拿到的任务描述和用户真实意图之间出现了偏差。这种偏差在简单任务上可能无关紧要Agent 可以通过上下文推断自动纠错。但在多步 Agent 任务中一个小偏差会被逐渐放大。比如第一步把“会议记录”理解成“会议纪律”后续查询、摘要、发送邮件都建立在错误前提上最后结果可能完全不对。所以“打字还是说话”这个表面选择本质上是在选择一个“输入噪声模型”。作为开发者不能假设 Agent 能自动处理所有输入方式而是要针对不同输入方式的扰动特征做专门适配。1.3 为什么这个话题在 Agent 时代变得更关键传统聊天机器人里输入方式的影响相对单一模型根据文本生成回答错误通常只影响单轮回复。但 LLM Agent 不一样Agent 会把输入转成一系列行动比如查数据库、调 API、发邮件、写文件。输入扰动从“影响一句话的意思”升级成了“影响一整条行动链路的起点”。这也是为什么相关研究里会专门把“语音输入扰动”和“键盘输入扰动”放在一起比较。它们既要回答“哪种输入方式更可靠”更要回答“Agent 应该如何设计才能对输入扰动更鲁棒”。2. 两种输入扰动的来源和差异2.1 语音输入的扰动不只是识别错误很多人以为语音输入的扰动就是 ASR 识别错几个字。真实使用中问题比这复杂得多。第一类是转写错误。包括同音字混淆、多音字误判、专有名词错转比如把“Vite”转成“外特”把“React”转成“瑞艾克特”。这类错误对普通对话影响不大人类可以结合上下文排除但 Agent 的参数抽取可能直接卡住。第二类是结构缺失。ASR 输出通常没有标点也分不清大小写。这会导致 Agent 难以判断一句话的边界、主谓宾关系、列表项。比如“把A和B、C加进清单”和“把A和BC加进清单”没有标点时会产生严重歧义。第三类是口语表达带来的冗余和碎片化。用户说话时习惯带“嗯”“那个”“就是说”还会临时改口“不对不要这个我是说……”。ASR 可能会把这些原样保留变成一句逻辑混乱的指令。键盘输入通常是经过思考后的产出口语则更像思维流的直接映射。第四类是环境噪声和口音干扰。这是 ASR 层面的经典问题但在 Agent 场景下影响会被放大。如果用户在嘈杂环境里让 Agent 设置定时任务一个数字识别错整个任务就错了。2.2 键盘输入的扰动看起来干净其实暗藏问题3. 单次跑通不等于稳定需要评测输入扰动的影响3.1 一套简单的输入扰动评测流程3.2 构造任务集时要覆盖哪几类难度3.3 从评测结果看什么情况下语音和键盘差距最大4. 缓解输入扰动从输入侧、Agent 侧到评测侧4.1 输入侧先做好文本规范化4.2 Agent 侧用提示词和流程设计提升鲁棒性4.3 评测侧把输入扰动做成回归测试集5. 实际落地时的排查链路与长期建议5.1 语音输入下 Agent 表现差先按这个顺序排查5.2 面向真实产品的四条经验5.3 这类研究的真正价值不在“二选一”而在于让 Agent 更鲁棒3. 单次跑通不等于稳定需要评测输入扰动的影响3.1 一套简单的输入扰动评测流程很多团队在验证 Agent 时只用了键盘输入而且是工整、规范的键盘输入。这会造成一种隐性偏差Agent 在干净输入下表现很好一到真实用户手里就“变笨”。真实用户不会像写测试用例一样打字更不会像播音员一样对着语音输入说话。所以我们要把输入扰动纳入评测体系。这里可以设计一套相对简单的评测流程用来量化不同输入方式对 Agent 的影响。第一步准备一组典型 Agent 任务。不要只准备简单任务要覆盖三类难度单步指令比如“查询一下杭州明天的天气”。多步指令比如“找到最近一周所有未读邮件里包含‘预算’的邮件提取金额按大小排序生成表格”。复杂约束指令比如“把今天会议记录的第三段转成待办事项优先级按紧急程度排只保留和设计相关的然后创建一个新的共享文档把链接发给我”。第二步为每个任务准备两种输入样本。键盘样本就是原始文本语音样本则要通过 ASR 转写得到。如果是测试可以直接用语音讲一遍再转写如果想控制变量可以预先构造一组带 ASR 错误的文本模拟真实语音输入。第三步记录 Agent 的执行结果并定义成功标准。简单任务可以只看最终输出是否正确多步任务还要看每一步的工具调用是否正确、是否存在错误前提复杂任务需要看约束是否全部满足有没有遗漏关键条件。第四步分别统计语音输入和键盘输入的成功率、平均执行时长、需要用户纠正的次数。这里建议把“一次成功”和“经过重新输入或澄清后成功”分开统计因为真实产品里用户会纠错但纠错本身也是成本。表格对照组设计维度键盘输入语音输入输入文本形态有标点、规范拼写、结构清晰无标点、可能有同音字错误、口语词多典型任务类型适合编码、搜索、精确指令适合闲聊、快速创建、简单查询主要扰动来源拼写错误、缩写、省略标点、复制粘贴脏数据ASR 转写错误、断句缺失、语气词、口音、环境噪声对 Agent 影响偏重信息缺失和信息污染偏重语义歧义和参数抽取错误评测重点错误令牌率、工具调用参数准确率意图识别准确率、复述澄清次数、最终任务成功率注意不要一上来就做大规模测试。先选 10 到 20 个代表性任务先把流程跑通再逐步扩大任务集。评测脚本和结果记录结构先固定否则后期数据不一致很难对比。3.2 构造任务集时要覆盖哪几类难度从标题看“A Comprehensive Study of Voice and Keyboard Input Perturbations”这类研究通常会构建一个任务集用来系统测量不同输入扰动对 Agent 行为的影响。我们自己落地时不一定需要学术级的实验设计但至少要覆盖三类关键难度否则评测结论没有参考价值。第一类是“信息精度敏感”任务。比如日期、时间、数字、金额、邮箱、域名。语音输入里“15:30”可能被转成“十五点三十”“12345”可能被转成“一万二千三百四十五”键盘输入里则可能出现顺手把“15:30”打成“15:300”。这类任务最容易暴露参数抽取问题。第二类是“多条件约束”任务。比如“排除掉已归档的文件”“只总结上周的数据”“优先处理高优先级标签”。语音输入常常丢掉否定词或把“不要”识别成“要把”键盘输入则容易把条件写含糊比如“上周数据”到底是“上周一到周日”还是“最近七个自然日”。这类任务考验 Agent 是否会在不确定性下主动澄清。第三类是“长上下文多步操作”任务。比如“你先把 A 文档翻译成英文然后提取里面的技术名词再搜索这些名词在我们内部的 wiki 页面最后生成一份术语对照表”。语音输入时长指令很容易在中间断开或被 ASR 分段导致 Agent 只执行后半段键盘输入时用户可能省略连接词让整条指令看起来像两件独立的事。这类任务能检验 Agent 是否具备全局规划能力。此外建议在评测集中加入“含错指令”。例如故意在语音转写文本里加入一个明显的同音错字看看 Agent 是机械执行还是能通过上下文自纠正。这比只测“顺利输入”更能反映鲁棒性。3.3 从评测结果看什么情况下语音和键盘差距最大按经验来看语音和键盘的表现差距会随任务复杂度上升而拉大。简单任务里两种输入方式的成功率可能差别不大因为 Agent 可以靠常识补全。但在多步、多约束、信息精确度高的任务中语音输入的失败率通常会明显高于键盘输入。这个差异主要来自三方面一是结构化信息的丢失。键盘能提供明确的分隔符和标点语音没有。二是错误纠正的隐性成本。键盘输错了用户能直观看到并修改语音输错了很多用户根本不会检查转写文本直接把错误的文本发给了 Agent。三是口语表达的模糊性。用户对 Agent 说话时容易省略主语和宾语默认 Agent 能像人一样理解“把昨天那个发给他”。反过来也存在一些语音表现更好的场景。比如开放式的头脑风暴、快速记录想法、临时创建一个提醒。这类任务对格式和参数要求不高Agent 只要能抓住大意就可以执行。语音输入的速度优势会比较明显。所以一个稳妥的结论是不要问“语音和键盘哪个更好”要问“在当前任务类型下哪种输入方式产生的扰动更小并且 Agent 是否能承受这种扰动”。把这个问法放进评测体系你才能得到真正对产品有指导意义的数据。4. 缓解输入扰动从输入侧、Agent 侧到评测侧4.1 输入侧先做好文本规范化面对语音和键盘带来的输入扰动第一道防线是输入文本规范化。不要指望 LLM 自己纠正所有问题那是在给模型增加不必要的负担。规范化处理越早Agent 的后续推理就越稳定。对语音输入建议按顺序做以下处理去语气词把“呃”“嗯”“那个”“就是说”等口语填充词去掉。可以用正则或词表过滤但要注意不能误删有实际语义的词。标点恢复ASR 通常不输出标点需要调用标点恢复模型或者直接交给 LLM 做轻量级分段。更实际的做法是在传给 Agent 之前让一个快速模型先把语音转文本重新组织成通顺的句子。同音词纠错如果是领域内高频词可以维护一份“误识别→正确词”的映射表。比如把“会议纪律”纠正为“会议记录”。这个表需要从用户反馈和日志中持续积累。数字格式化把“十五点三十”转成“15:30”把“一万二千三百四十五”转成“12345”。这类转换规则明确应该用规则处理而不是丢给随机性更强的 LLM。关键信息确认如果任务中检测到时间、日期、金额、邮件地址、手机号等关键实体可以考虑在正式执行前要求用户确认一次。这个成本不高但能避免大量严重错误。对键盘输入规范化同样重要。建议处理去除复制粘贴带来的多余换行、空格、不可见字符把全角标点转成半角识别常见拼写错误比如“conifg”纠正为“config”对明显过短的模糊指令可以主动追回“请补充任务对象或目标”。输入侧规范化的目标是“把有噪声的文本变成 Agent 更容易理解的规范文本”而不是“把用户的表达完全改写”。要保留用户的主要意图和个人风格否则会让对话显得机械。4.2 Agent 侧用提示词和流程设计提升鲁棒性即便做了输入侧规范化仍然会有错误漏过去。所以 Agent 本身也要具备对输入扰动的容忍机制。这里有几个可以落地的设计思路。第一要求 Agent 在不确定时主动澄清而不是猜测。可以在系统提示词里明确写“如果任务描述中存在时间、地点、对象、操作方式等关键信息缺失或歧义请先向用户确认再开始执行。”这个策略会牺牲一点响应速度但能避免多步任务在错误前提下跑完全程。第二让 Agent 在执行前先复述任务理解。对于多步任务可以让 Agent 先输出“我理解你的任务是……其中包含以下步骤……”确认无误后再执行。复述不是形式主义它能让用户发现输入扰动导致的偏差并及时纠正。第三用结构化工具调用来约束参数抽取。不要只让 Agent 从自由文本里猜参数而是定义一个工具调用 schema让 Agent 必须把参数填到固定字段里。比如{ action: send_email, params: { to: [project_teamexample.com], subject: 上周三会议纪要, body: …… } }如果参数缺失或格式不对工具调用层可以拦截并提示 Agent 补全。这比让 Agent 直接拼接 API 请求更容易发现扰动问题。第四针对语音输入特征可以准备一组“口语化改写模板”。例如用户说“把那个啥就是昨天我们讨论过的方案发给大家”Agent 可以尝试把“那个啥”“就是”解释为“昨天我们讨论过的方案”再执行。但这里要注意边界如果 Agent 无法确定“那个啥”指什么必须询问不能编造一个对象。4.3 评测侧把输入扰动做成回归测试集很多人会把输入规范化写在功能代码里却没有建立配套的回归测试集。这会导致一个隐蔽问题今天改了一个 ASR 对接逻辑语音输入成功率下降 10%但键盘输入测试全绿问题完全暴露不出来。建议把“输入扰动测试集”作为 Agent 项目的基础设施和普通单测、集成测试并列。扰动测试集里可以包含正常键盘输入样本带拼写错误的键盘输入样本带标点缺失的键盘输入样本口语化语音转写样本带同音字错误的语音转写样本带环境噪声和口音特征的 ASR 转写样本混合中英文和专有名词的样本。每次升级模型、修改提示词、调整输入处理管道后都跑一遍扰动测试集。对比前一次成功率如果出现明显下降说明这次改动对输入扰动更敏感了需要回滚或补充对策。这里给一个通用的检查顺序先看现象是意图识别错还是参数抽取错还是工具调用错还是最终输出错再看输入原始输入是什么规范化之后是什么Agent 实际收到的是什么再看环境ASR 版本、模型版本、提示词版本、工具定义版本是否一致再看参数Agent 的超参、温度、最大 token、工具调用限制是否合理最后看工具边界这个错误是输入扰动造成还是 Agent 本身不支持这种任务还是工具接口不稳定在这个过程中日志是最重要的。建议在 Agent 入口处把“原始输入文本”和“规范化后文本”都记录下来。否则排查时你连 Agent 实际收到的是什么都不知道。5. 实际落地时的排查链路与长期建议5.1 语音输入下 Agent 表现差先按这个顺序排查如果用户反馈“用语音叫 Agent 做事老是做错”不要急着换更大的模型。按照下面的链路排查大多数问题都会在前面几步暴露。先把原始语音转写文本调出来。很多团队没有记录这一步只能在 Agent 日志里看到最终执行结果根本找不到问题根源。所以第一步确认 ASR 转写文本是否准确。如果转写就已经错了问题不在 Agent在语音识别链路。做好这一步后再检查规范化是否生效。看看语气词有没有去掉标点有没有恢复数字有没有格式化。如果你做了一个“把口语词转成正式表达”的步骤但日志显示 Agent 收到的是原始口语文本那说明处理管道没有正确串联。接着检查 Agent 的提示词策略。Agent 是否被允许主动澄清还是它收到一句含糊指令后直接默认一个解释并开始执行很多 Agent 默认不会澄清因为模型倾向于“完成指令”。需要在提示词里显式强调。然后检查工具调用参数。如果 Agent 调用了工具但参数是错的要看参数是从规范文本中抽取的还是从原始文本中抽取的schema 里的字段名和 Agent 对文本的理解是否一致有没有对异常值做拦截最后再考虑模型能力。如果输入侧、规范化侧、提示词侧都没问题Agent 仍然无法从口语化文本中抽取正确参数那才需要考虑换更强的模型或增加少量示例。这个排查链路适用于大多数“Agent 表现不一致”的情况。不要一上来就调 temperature 或换模型先确认输入是被谁污染的。5.2 面向真实产品的四条经验结合做 Agent 的实践经验有几条建议值得分享。第一不要只做键盘输入的单模态测试。真实产品往往会集成语音入口用户会很自然地对 Agent 说话。如果你的评测集里没有语音转写样本你实际上无法知道 Agent 在真实场景里的表现。Voice input 在 Agent 产品里已经不是可选项而是必选项。不要等到用户反复抱怨后才补。第二给用户提供“输入确认”的成本要尽量低。语音输入后很多用户不会阅读转写文本。所以在任务执行前如果 Agent 能自动把关键参数列出来比如“你将查询上海办公室会议时间上周三操作整理摘要并发邮件”用户扫一眼就能发现错误比任务执行完才发现效率高得多。第三把输入扰动问题当作独立的工程模块而不是 LLM 推理能力的附属问题。输入规范化、纠错表、标点恢复、关键信息确认、回归测试集这些应该作为 Agent 基础设施的一部分持续迭代。尤其是语音输入ASR 领域本身就在不断变化你需要经常重新评估。第四给语音和键盘设计不同的交互路径。同一个 Agent 不一定非要使用完全相同的输入处理逻辑。键盘输入用户更“冷静”可以直接执行语音输入用户更“口语化”需要多做一层校验。让语音输入默认开启“关键信息确认”键盘输入默认不开启可以显著减少语音输入的失败率同时不牺牲键盘输入的效率。5.3 这类研究的真正价值不在“二选一”而在于让 Agent 更鲁棒回到标题Should We Type or Talk to LLM Agents? 如果把它当成一个二选一的问题很容易陷入“语音更自然”或“键盘更精确”的争论。但从工程视角看这个问题更准确的读法是在不同的输入方式下Agent 会遇到什么样的输入扰动以及我们如何让 Agent 对扰动不敏感。语音输入和键盘输入都不是完美的信息通道。它们各有噪声模式也各有信息优势。语音输入的转写错误、口语碎片、缺少标点是输入侧扰动键盘输入的拼写错误、缩写歧义、复制粘贴污染同样是输入侧扰动。Agent 如果只能处理一种噪声就很难成为真正通用的产品。所以我的建议是从今天开始把你项目的输入测试集里加上语音转写文本把输入规范化模块单独拆出来把“复述理解”作为多步任务的标准流程。这些改动并不复杂但能把 Agent 从“测试环境很聪明实际使用不靠谱”的状态拉回正轨。输入扰动不会消失。你越早承认它、测量它、处理它你的 Agent 就越可靠。