这次我们来看一个不太一样的研究方向和 LLM Agent 交互时用户到底应该打字还是说话以及当语音识别噪声、键盘抖动这类输入扰动混进来之后Agent 的任务执行会不会崩这个课题听起来像人机交互实际上是一个很典型的 LLM 鲁棒性问题。LLM Agent 和普通聊天机器人的区别在于它会执行工具调用、修改状态、触发动作输入侧多一个错字输出侧可能就多一次错误操作。“Should We Type or Talk to LLM Agents?”这项研究核心就是把输入方式、输入扰动和 Agent 任务表现放在同一个实验框架里做对照。从研究标题的几个关键词看它把输入方式拆成了 Voice 和 Keyboard 两条链路并把输入扰动作为核心变量。接下来我会围绕这个主题拆解两条输入链路的误差来源、可复现的实验设计、工程上如何做输入扰动回归测试以及哪些结论可以直接用到 Agent 产品里。如果你在开发 Agent 应用、做 LLM 自动化测试或者关心人机交互中的输入稳定性这篇文章值得读完。1. 核心信息速览信息项说明项目主题LLM Agent 输入方式对比研究语音输入 vs 键盘输入核心问题用户应打字还是语音与 Agent 交互输入扰动如何影响 Agent 行为输入方式Voice语音链路、Keyboard键盘链路扰动类型ASR 识别错误、键盘 chatter 抖动、HID 事件异常、蓝牙键盘延迟/丢包、输入法自动纠错等涉及技术栈LLM Agents、ASR、输入法、HID 键盘事件、Prompt Engineering、自动化评测实验形态控制变量对比、扰动注入、任务完成率/工具调用正确率/Token 消耗评估硬件要求取决于复现方案通常需要标准键盘或麦克风纯脚本评估不需要 GPU发布形态论文/研究报告输入材料未提供作者、机构、代码仓库与实验原始数据适合读者Agent 应用开发者、LLM 质量保障工程师、人机交互研究者、Agent 框架设计者这里要说明一点输入材料没有提供论文原文、实验数据或开源代码所以下面所有实验设计、指标建议和工程结论都是基于标题、关键词和相关技术实践做的合理拆解不代表论文原文内容。想拿真实数据的话需要以正式发表的论文和配套材料为准。2. 研究背景输入方式为什么会影响 Agent 行为LLM Agent 和传统的单轮问答不同。它把自然语言指令解析成意图再映射到工具调用最后还要根据工具返回结果继续决策。整个过程往往是多轮的Agent 可能先搜索信息再写入数据库再调用外部 API最后生成总结。只要最前面的指令被理解错后面每一轮都会沿着错误方向继续推进。键盘输入和语音输入最终都会变成文本进入 Agent但这条“文本化”路径的噪声来源完全不同。键盘输入更接近用户的原始意图但会遇到输入法自动纠错、中英文标点混用、全角半角切换、物理按键抖动产生的重复字符语音输入面向口语ASR 模型天然存在同音字、多音字、口音、背景噪声和数字单位识别问题。这些都是“输入扰动”。传统评测很少把输入扰动作为独立变量。大多数 Agent 测试用的是人工写好的干净 prompt直接丢给模型看输出对不对。这种测试能反映模型推理能力但反映不了真实用户输入质量。真实场景中用户可能是在地铁上用语音快速说一句指令也可能是在嘈杂环境里用蓝牙键盘打字输入层已经带上了噪声。所以这项研究的价值在于把“打字还是说话”从用户体验问题转成了一个可测量、可干预的输入侧质量问题。对于 Agent 工程化来说输入扰动不是“显示层小问题”而是可能直接导致错误工具调用的执行层问题。3. 两条输入链路与扰动来源3.1 键盘输入链路键盘输入的完整链路是用户物理按键 → HID 键盘设备 → 操作系统驱动 → 输入法/编辑器 → 文本 → LLM Agent API。这条链路上的扰动来源分布很广。第一类是硬件层键盘抖动也就是常说的 keyboard chatter。机械键盘或老化键盘在按键闭合瞬间可能产生多次电信号导致一个字符被输入两次比如“help”变成“heeelp”。这类问题在系统层通常有专门的 keyboard chatter blocker 工具来过滤但并不是所有用户都会安装也不是所有 Agent 产品都会对文本做去重清洗。第二类是 HID 键盘设备事件异常。有些设备在电量低、休眠唤醒或驱动异常时会重复发送按键事件等效于输入注入。对 Agent 来说这等于无端多出了几个字符可能打断指令结构。第三类是蓝牙键盘的延迟与丢包。蓝牙协议在 2.4GHz 频段繁忙时可能出现按键事件丢失或重复发送用户以为自己打的是“list files”实际传进系统的可能是“ist files”或者“llist files”。第四类是输入法层的自动纠错和联想改写。中文输入法、英文拼写检查都会在用户确认前改写文本如果用户没仔细看回显错误文本就会直接进入 Agent。3.2 语音输入链路语音输入链路是用户说话 → 麦克风 → ASR 模型 → 文本 → LLM Agent API。ASR 的扰动类型更复杂。同音字错误是最常见的比如“周三”被识别成“周日”“删除”被识别成“山区”多音字、专业术语、人名地名也会引入错误。远场语音和背景噪声会进一步降低识别置信度。另一个容易被忽略的问题是标点和语气信息丢失。键盘输入时用户会主动加逗号、句号、问号语音输入转写出来往往是一长串不带标点的句子。Agent 在解析这种长文本时可能无法准确切分指令边界导致多步任务被合并或遗漏。ASR 幻觉也不容忽视。在静音片段或极低信噪比场景下部分 ASR 模型会生成无意义词这些词会被 Agent 当成真实指令的一部分。比起键盘输入的多余字符ASR 幻觉更像是一段“语义噪声”处理的难度更高。3.3 输入扰动如何被 Agent 放大单看文本错误语音输入的错误率通常高于键盘输入但这只是第一步。关键问题在于 Agent 会把文本转换成动作。用户对 Agent 说“不要发这封邮件”ASR 如果识别成“要发这封邮件”就是一个语义反转指令用户键盘输入时如果输入法自动纠错把“不”改成“部”Agent 很可能直接忽略否定词。这类扰动在聊天场景里最多让回复不准确在 Agent 场景里却会造成实际动作错误。也就是说输入扰动在 Agent 系统里具有“放大效应”。第一轮的错误文本会进入工具调用参数工具返回错误结果Agent 再基于错误结果继续推理形成错误链。要评估输入扰动的影响不能只看文本相似度必须看最终任务完成率和工具调用链路是否被污染。4. 实验设计如何对比打字和语音的差异原始材料没有给出这篇论文的具体实验方案。如果我们要复现或者验证这个研究方向可以按下面的框架设计一套对照实验这也是同类研究中比较稳妥的做法。先定自变量和因变量。自变量 1输入方式分为纯键盘、纯语音、混合输入三组。自变量 2扰动等级分为无扰动、轻度扰动、重度扰动。自变量 3任务复杂度分为单步指令、多步指令、需要调用外部工具的任务。因变量任务完成率、首轮正确率、工具调用参数错误率、平均 Token 消耗、用户修正次数。实验数据集建议准备 50 到 100 条任务指令覆盖四类场景信息查询、文本编辑、工具调用、多步规划。每条指令都要有标准答案和标注好的关键实体比如日期、文件名、收件人、金额。扰动注入是关键环节。可以使用规则化方式快速模拟也可以用真实 ASR 模型和真实键盘事件来做端到端验证。规则注入的好处是可控、可复现适合先定位问题真实模型的好处是贴近线上但扰动不可控不适合做回归基线。下面是一段用 Python 模拟键盘 chatter 抖动的脚本用于生成扰动后的输入文本import random def inject_keyboard_chatter(text: str, repeat_prob: float 0.05) - str: 模拟键盘抖动导致的字符重复。 每个非空格字符有 repeat_prob 的概率被重复一次 用于模拟 HID 键盘设备在机械抖动时产生的重复按键事件。 result [] for ch in text: result.append(ch) if ch ! and random.random() repeat_prob: result.append(ch) return .join(result) # 示例 random.seed(42) clean_prompt list all files in /tmp and delete old logs noisy_prompt inject_keyboard_chatter(clean_prompt, repeat_prob0.08) print(noisy_prompt) # 输出可能是llist all files in /tmp annd delete old logss用真实音频做语音扰动测试时建议直接让 ASR 模型输出作为 Agent 输入。如果只是想验证 Agent 对同音字错误的鲁棒性可以先用规则替换HOMOPHONE_MAP { 周三: 周日, 删除: 山区, 发送: 发散, 附件: 副件, } def inject_asr_homophone_error(text: str) - str: 模拟 ASR 同音字错误注意这是简化版本。 真实 ASR 错误分布更随机这里只用于快速构造扰动样本。 for correct, wrong in HOMOPHONE_MAP.items(): text text.replace(correct, wrong) return text prompt 把周二的附件发送给项目组 noisy_prompt inject_asr_homophone_error(prompt) print(noisy_prompt)每个任务建议重复执行 5 到 10 次固定模型温度和随机种子取平均结果。这样能过滤掉单选采样的随机波动让任务完成率具备可比性。5. 结果应该看什么可用评价指标实验做完之后不能只盯着“回答内容像不像”要重点看 Agent 的执行链路有没有被输入扰动带偏。评估维度计算方式观察重点使用建议任务完成率成功完成任务数 / 总任务数输入扰动对最终结果的整体影响核心指标必须与其他维度一起看首轮正确率仅第一次执行就成功的任务比例扰动是否直接影响指令理解前期定位问题最有效工具调用参数错误率工具参数与标准答案不一致的次数 / 总调用次数实测扰动是否污染结构化参数Agent 场景必看平均 Token 消耗总 Token / 任务数输入噪声是否导致模型反复纠偏反映成本影响用户修正次数每任务平均需要修正的轮数扰动带来的交互成本结合主观体验指令语义反转率语义反转任务中执行错误的比例否定词、程度词被扰动后是否反转高风险场景单独统计直观来说最值得关注的是“工具调用参数错误率”。同一个 Agent在 clean 输入下参数全对加了扰动后日期参数错了这才是输入扰动造成的真实破坏。如果只是输出文本有偏差很多时候用户还能通过后续对话纠偏如果工具参数错了文件可能已经被移动、邮件可能已经发出。另外要区分“文本相似度下降”和“任务失败”。有时候 ASR 把“附件”识别成“副件”但 Agent 通过上下文能推断出用户意图任务照样成功有时候一个标点符号错了反而改变了指令结构。所以评估时必须以任务结果为准不要用文本编辑距离替代任务完成率。6. 对 Agent 工程实践的启发从研究角度看这个课题的价值在量化。从工程角度看输入扰动是可以被缓解的。第一建一条输入标准化管道。不管文本来自键盘还是语音进入 Agent 之前先做一次清洗。清洗内容包括连续重复字符去重、全角半角统一、中英文标点统一、常见同音字纠错、口头语气词去除。下面是简化示例import re def normalize_agent_input(text: str) - str: Agent 输入标准化去重复字符、统一标点、去口头语气词。 # 连续重复字符压缩适合处理键盘 chatter # 注意对中文叠词可能误伤需要按业务调整 text re.sub(r(.)\1{2,}, r\1, text) # 全角转半角基础版实现 text text.replace(, ,).replace(。, .).replace(, ?).replace(, !) # 常见语音口头语 text re.sub(r嗯|额|那个|就是, , text) return text.strip() raw 嗯帮我把文件移到 /tmp/logss就是那个文件 print(normalize_agent_input(raw))这种管道不是万能的但能挡住一批低质量输入。关键是要在离线数据集上反复验证清洗规则不会误伤正常指令。第二为高风险操作增加确认。输入扰动再清洗也没法保证 100% 正确尤其是语义反转类型的错误。Agent 在执行删除、发送、转账、修改权限这类动作前应该把解析出的关键参数回显给用户让用户确认一次。这个确认成本远低于错误操作后的恢复成本。第三Agent 内部要做参数校验。如果 Agent 要调用的工具函数有明确类型和取值枚举不要直接把 LLM 输出转成参数要先做类型校验。比如日期字段必须是 YYYY-MM-DD 格式路径字段必须指向允许访问的目录收件人字段必须在通讯录白名单内。输入扰动就算骗过了 LLM也会被参数校验拦下来。第四日志要记录输入侧原始内容不能只记录“清洗后的文本”。否则用户反馈“我说的是周三Agent 执行成了周日”时你根本没法确认是 ASR 错了还是模型理解错了。7. 自动化回归测试与扰动注入实验平台如果要把这个研究方向落地成 Agent 产品的质量保障能力可以搭一套输入扰动回归测试平台。核心思路是准备基准任务集 → 注入扰动 → 调用 Agent → 记录结果 → 对比基线指标。下面是一个简化版的批量评估脚本框架import json import requests import random TASKS [ {id: T001, prompt: 查询上海周三的天气, expected_action: weather_query, expected_params: {city: 上海, date: 周三}}, {id: T002, prompt: 删除 /tmp/old.log 文件, expected_action: file_delete, expected_params: {path: /tmp/old.log}}, ] def inject_perturbation(text: str, level: str) - str: if level none: return text if level low: return inject_keyboard_chatter(text, repeat_prob0.03) if level high: return inject_keyboard_chatter(text, repeat_prob0.08) return text def call_agent(prompt: str, api_url: str) - dict: 调用 Agent 服务接口。实际请求结构以你的后端为准。 resp requests.post(api_url, json{prompt: prompt, task_type: tool_call}, timeout120) resp.raise_for_status() return resp.json() def evaluate(level: str, api_url: str, repeat: int 3): results [] for task in TASKS: for i in range(repeat): noisy_prompt inject_perturbation(task[prompt], level) try: output call_agent(noisy_prompt, api_url) # 这里需要根据实际 Agent 响应结构解析 action 和 params action_ok output.get(action) task[expected_action] params_ok output.get(params) task[expected_params] results.append({ task_id: task[id], level: level, success: action_ok and params_ok, output: output, }) except Exception as exc: results.append({ task_id: task[id], level: level, success: False, error: str(exc), }) return results if __name__ __main__: random.seed(7) api_url http://127.0.0.1:8000/agent for level in [none, low, high]: result evaluate(level, api_url) ok sum(1 for r in result if r[success]) print(flevel{level}, success{ok}/{len(result)})这套框架有几个注意点。一是接口路径和请求体必须按你自己的 Agent 服务调整上面只是通用模板二是每次实验要固定扰动种子确保不同模型版本之间对比有效三是批量跑完要保存完整结果 JSON包括失败样本的输入、输出和错误信息方便后续定位。还可以用 pynput 或 PyAutoGUI 模拟真实键盘事件配合输入延迟和重复按键做端到端测试。这种测试更接近真实环境但执行速度慢适合小样本回归不适合大批量评测。8. 性能观察输入侧延迟与 Token 成本这个研究方向还会牵出一个工程问题输入扰动不仅影响正确率还影响延迟和成本。语音链路天然会引入 ASR 延迟。本地 ASR 通常需要几百毫秒到几秒云端 ASR 还多一次网络往返。键盘输入理论上延迟更低但如果输入法有复杂的联想和纠错也可能在用户端造成等待。对 Agent 来说输入侧延迟会直接叠加到整体响应时间上。Token 成本也不一样。语音转写文本通常包含更多口语化内容长度更长键盘输入如果产生重复字符清洗前也会浪费 Token。输入扰动导致 Agent 多轮纠偏时Token 消耗会进一步上升。从研究的角度看可以统计同一个任务集在 clean 和 noisy 两种输入下的平均 Token 差值这部分多出来的成本就是“扰动税”。观察资源占用时建议在 Agent 服务端记录三个时间戳收到输入文本的时间、第一次工具调用的时间、最终响应时间。再结合输入日志里原始文本和清洗后文本的长度就能估算输入扰动对性能和成本的实际影响。9. 常见问题与排查方法问题现象可能原因排查方式解决方案语音输入后 Agent 执行了错误动作ASR 识别错误未被清洗查看输入日志原始转录文本增加同音字纠错和关键动作二次确认键盘输入出现重复字符键盘 chatter 抖动用 HID 事件测试工具观察按键事件系统层加键盘抖动过滤文本层做去重清洗蓝牙键盘输入时字符丢失蓝牙唤醒丢包或干扰查看系统事件日志尝试固件更新输入回显确认关键指令核对Agent 多轮后偏离任务输入扰动被逐轮放大对比第一轮和最终轮状态增加中间状态校验和任务快照批量评估结果不可复现未固定随机种子或扰动脚本版本检查实验配置固定 random seed记录扰动代码版本清洗规则误伤正常指令去重或语气词规则过强检查误伤样本用离线数据集验证清洗规则按业务调优比较隐蔽的坑是“清洗规则误伤”。比如中文里的叠词“看看”“试试”如果被重复字符压缩规则处理可能变成“看”“试”语义虽然没变但语气变了。所以清洗管道的规则要在业务数据集上做回归不能只看几个样例就上线。10. 最佳实践与使用建议先小步试跑。不要一上来就在全部任务集上跑高扰动等级先用 20 条指令、低扰动等级验证测试框架本身是否可靠。保留一套最小可复现配置。固定任务集、固定扰动种子、固定模型温度这些元信息要随实验结果一起保存。模型文件、测试数据、扰动脚本、输出结果分目录管理。建议按实验日期和模型版本建子目录避免结果互相覆盖。批量任务要加日志和失败重试。Agent 接口偶发超时很正常测试脚本要能区分“接口失败”和“任务执行失败”。涉及人脸、声音、用户输入数据时必须确认授权和隐私合规。语音输入数据包含用户生物特征键盘输入可能包含密码和敏感内容采集和存储都要做脱敏和访问控制。高风险操作要做人工确认。删除、发送、支付、权限变更类工具调用无论输入多干净都要保留确认环节。11. 总结这个研究方向最值得尝试的点是把“打字还是语音”从个人偏好问题变成了一个可以测量、可以优化、可以在工程上拦截的输入质量问题。比起继续争论哪种输入更好更实际的做法是先在自己的 Agent 里跑一遍 clean 输入和扰动输入的对比看看任务完成率掉了多少再决定投入多少资源做输入清洗和回显确认。最先应该验证的功能是“工具调用参数错误率”。用 50 条指令分别跑干净输入、键盘扰动输入、ASR 扰动输入对比工具调用的 action 和 params 正确率。只要参数错误率明显上升就说明你的 Agent 输入侧存在真实风险。最容易踩的坑是用真实 ASR 模型做扰动注入时扰动不可控最后说不清结果是模型问题还是 ASR 问题。建议先用规则扰动定位 Agent 的薄弱点再用真实 ASR 模型做端到端验证。后续可以继续扩展的方向很多多语言输入扰动、Agent 多轮轨迹级评测、工具参数约束自动校验、以及“混合输入模式”下的交互设计。如果你正在做 Agent 应用这个课题值得跟进。 LLM Agent交互：语音与键盘输入扰动对任务执行的影响与测试实践
这次我们来看一个不太一样的研究方向和 LLM Agent 交互时用户到底应该打字还是说话以及当语音识别噪声、键盘抖动这类输入扰动混进来之后Agent 的任务执行会不会崩这个课题听起来像人机交互实际上是一个很典型的 LLM 鲁棒性问题。LLM Agent 和普通聊天机器人的区别在于它会执行工具调用、修改状态、触发动作输入侧多一个错字输出侧可能就多一次错误操作。“Should We Type or Talk to LLM Agents?”这项研究核心就是把输入方式、输入扰动和 Agent 任务表现放在同一个实验框架里做对照。从研究标题的几个关键词看它把输入方式拆成了 Voice 和 Keyboard 两条链路并把输入扰动作为核心变量。接下来我会围绕这个主题拆解两条输入链路的误差来源、可复现的实验设计、工程上如何做输入扰动回归测试以及哪些结论可以直接用到 Agent 产品里。如果你在开发 Agent 应用、做 LLM 自动化测试或者关心人机交互中的输入稳定性这篇文章值得读完。1. 核心信息速览信息项说明项目主题LLM Agent 输入方式对比研究语音输入 vs 键盘输入核心问题用户应打字还是语音与 Agent 交互输入扰动如何影响 Agent 行为输入方式Voice语音链路、Keyboard键盘链路扰动类型ASR 识别错误、键盘 chatter 抖动、HID 事件异常、蓝牙键盘延迟/丢包、输入法自动纠错等涉及技术栈LLM Agents、ASR、输入法、HID 键盘事件、Prompt Engineering、自动化评测实验形态控制变量对比、扰动注入、任务完成率/工具调用正确率/Token 消耗评估硬件要求取决于复现方案通常需要标准键盘或麦克风纯脚本评估不需要 GPU发布形态论文/研究报告输入材料未提供作者、机构、代码仓库与实验原始数据适合读者Agent 应用开发者、LLM 质量保障工程师、人机交互研究者、Agent 框架设计者这里要说明一点输入材料没有提供论文原文、实验数据或开源代码所以下面所有实验设计、指标建议和工程结论都是基于标题、关键词和相关技术实践做的合理拆解不代表论文原文内容。想拿真实数据的话需要以正式发表的论文和配套材料为准。2. 研究背景输入方式为什么会影响 Agent 行为LLM Agent 和传统的单轮问答不同。它把自然语言指令解析成意图再映射到工具调用最后还要根据工具返回结果继续决策。整个过程往往是多轮的Agent 可能先搜索信息再写入数据库再调用外部 API最后生成总结。只要最前面的指令被理解错后面每一轮都会沿着错误方向继续推进。键盘输入和语音输入最终都会变成文本进入 Agent但这条“文本化”路径的噪声来源完全不同。键盘输入更接近用户的原始意图但会遇到输入法自动纠错、中英文标点混用、全角半角切换、物理按键抖动产生的重复字符语音输入面向口语ASR 模型天然存在同音字、多音字、口音、背景噪声和数字单位识别问题。这些都是“输入扰动”。传统评测很少把输入扰动作为独立变量。大多数 Agent 测试用的是人工写好的干净 prompt直接丢给模型看输出对不对。这种测试能反映模型推理能力但反映不了真实用户输入质量。真实场景中用户可能是在地铁上用语音快速说一句指令也可能是在嘈杂环境里用蓝牙键盘打字输入层已经带上了噪声。所以这项研究的价值在于把“打字还是说话”从用户体验问题转成了一个可测量、可干预的输入侧质量问题。对于 Agent 工程化来说输入扰动不是“显示层小问题”而是可能直接导致错误工具调用的执行层问题。3. 两条输入链路与扰动来源3.1 键盘输入链路键盘输入的完整链路是用户物理按键 → HID 键盘设备 → 操作系统驱动 → 输入法/编辑器 → 文本 → LLM Agent API。这条链路上的扰动来源分布很广。第一类是硬件层键盘抖动也就是常说的 keyboard chatter。机械键盘或老化键盘在按键闭合瞬间可能产生多次电信号导致一个字符被输入两次比如“help”变成“heeelp”。这类问题在系统层通常有专门的 keyboard chatter blocker 工具来过滤但并不是所有用户都会安装也不是所有 Agent 产品都会对文本做去重清洗。第二类是 HID 键盘设备事件异常。有些设备在电量低、休眠唤醒或驱动异常时会重复发送按键事件等效于输入注入。对 Agent 来说这等于无端多出了几个字符可能打断指令结构。第三类是蓝牙键盘的延迟与丢包。蓝牙协议在 2.4GHz 频段繁忙时可能出现按键事件丢失或重复发送用户以为自己打的是“list files”实际传进系统的可能是“ist files”或者“llist files”。第四类是输入法层的自动纠错和联想改写。中文输入法、英文拼写检查都会在用户确认前改写文本如果用户没仔细看回显错误文本就会直接进入 Agent。3.2 语音输入链路语音输入链路是用户说话 → 麦克风 → ASR 模型 → 文本 → LLM Agent API。ASR 的扰动类型更复杂。同音字错误是最常见的比如“周三”被识别成“周日”“删除”被识别成“山区”多音字、专业术语、人名地名也会引入错误。远场语音和背景噪声会进一步降低识别置信度。另一个容易被忽略的问题是标点和语气信息丢失。键盘输入时用户会主动加逗号、句号、问号语音输入转写出来往往是一长串不带标点的句子。Agent 在解析这种长文本时可能无法准确切分指令边界导致多步任务被合并或遗漏。ASR 幻觉也不容忽视。在静音片段或极低信噪比场景下部分 ASR 模型会生成无意义词这些词会被 Agent 当成真实指令的一部分。比起键盘输入的多余字符ASR 幻觉更像是一段“语义噪声”处理的难度更高。3.3 输入扰动如何被 Agent 放大单看文本错误语音输入的错误率通常高于键盘输入但这只是第一步。关键问题在于 Agent 会把文本转换成动作。用户对 Agent 说“不要发这封邮件”ASR 如果识别成“要发这封邮件”就是一个语义反转指令用户键盘输入时如果输入法自动纠错把“不”改成“部”Agent 很可能直接忽略否定词。这类扰动在聊天场景里最多让回复不准确在 Agent 场景里却会造成实际动作错误。也就是说输入扰动在 Agent 系统里具有“放大效应”。第一轮的错误文本会进入工具调用参数工具返回错误结果Agent 再基于错误结果继续推理形成错误链。要评估输入扰动的影响不能只看文本相似度必须看最终任务完成率和工具调用链路是否被污染。4. 实验设计如何对比打字和语音的差异原始材料没有给出这篇论文的具体实验方案。如果我们要复现或者验证这个研究方向可以按下面的框架设计一套对照实验这也是同类研究中比较稳妥的做法。先定自变量和因变量。自变量 1输入方式分为纯键盘、纯语音、混合输入三组。自变量 2扰动等级分为无扰动、轻度扰动、重度扰动。自变量 3任务复杂度分为单步指令、多步指令、需要调用外部工具的任务。因变量任务完成率、首轮正确率、工具调用参数错误率、平均 Token 消耗、用户修正次数。实验数据集建议准备 50 到 100 条任务指令覆盖四类场景信息查询、文本编辑、工具调用、多步规划。每条指令都要有标准答案和标注好的关键实体比如日期、文件名、收件人、金额。扰动注入是关键环节。可以使用规则化方式快速模拟也可以用真实 ASR 模型和真实键盘事件来做端到端验证。规则注入的好处是可控、可复现适合先定位问题真实模型的好处是贴近线上但扰动不可控不适合做回归基线。下面是一段用 Python 模拟键盘 chatter 抖动的脚本用于生成扰动后的输入文本import random def inject_keyboard_chatter(text: str, repeat_prob: float 0.05) - str: 模拟键盘抖动导致的字符重复。 每个非空格字符有 repeat_prob 的概率被重复一次 用于模拟 HID 键盘设备在机械抖动时产生的重复按键事件。 result [] for ch in text: result.append(ch) if ch ! and random.random() repeat_prob: result.append(ch) return .join(result) # 示例 random.seed(42) clean_prompt list all files in /tmp and delete old logs noisy_prompt inject_keyboard_chatter(clean_prompt, repeat_prob0.08) print(noisy_prompt) # 输出可能是llist all files in /tmp annd delete old logss用真实音频做语音扰动测试时建议直接让 ASR 模型输出作为 Agent 输入。如果只是想验证 Agent 对同音字错误的鲁棒性可以先用规则替换HOMOPHONE_MAP { 周三: 周日, 删除: 山区, 发送: 发散, 附件: 副件, } def inject_asr_homophone_error(text: str) - str: 模拟 ASR 同音字错误注意这是简化版本。 真实 ASR 错误分布更随机这里只用于快速构造扰动样本。 for correct, wrong in HOMOPHONE_MAP.items(): text text.replace(correct, wrong) return text prompt 把周二的附件发送给项目组 noisy_prompt inject_asr_homophone_error(prompt) print(noisy_prompt)每个任务建议重复执行 5 到 10 次固定模型温度和随机种子取平均结果。这样能过滤掉单选采样的随机波动让任务完成率具备可比性。5. 结果应该看什么可用评价指标实验做完之后不能只盯着“回答内容像不像”要重点看 Agent 的执行链路有没有被输入扰动带偏。评估维度计算方式观察重点使用建议任务完成率成功完成任务数 / 总任务数输入扰动对最终结果的整体影响核心指标必须与其他维度一起看首轮正确率仅第一次执行就成功的任务比例扰动是否直接影响指令理解前期定位问题最有效工具调用参数错误率工具参数与标准答案不一致的次数 / 总调用次数实测扰动是否污染结构化参数Agent 场景必看平均 Token 消耗总 Token / 任务数输入噪声是否导致模型反复纠偏反映成本影响用户修正次数每任务平均需要修正的轮数扰动带来的交互成本结合主观体验指令语义反转率语义反转任务中执行错误的比例否定词、程度词被扰动后是否反转高风险场景单独统计直观来说最值得关注的是“工具调用参数错误率”。同一个 Agent在 clean 输入下参数全对加了扰动后日期参数错了这才是输入扰动造成的真实破坏。如果只是输出文本有偏差很多时候用户还能通过后续对话纠偏如果工具参数错了文件可能已经被移动、邮件可能已经发出。另外要区分“文本相似度下降”和“任务失败”。有时候 ASR 把“附件”识别成“副件”但 Agent 通过上下文能推断出用户意图任务照样成功有时候一个标点符号错了反而改变了指令结构。所以评估时必须以任务结果为准不要用文本编辑距离替代任务完成率。6. 对 Agent 工程实践的启发从研究角度看这个课题的价值在量化。从工程角度看输入扰动是可以被缓解的。第一建一条输入标准化管道。不管文本来自键盘还是语音进入 Agent 之前先做一次清洗。清洗内容包括连续重复字符去重、全角半角统一、中英文标点统一、常见同音字纠错、口头语气词去除。下面是简化示例import re def normalize_agent_input(text: str) - str: Agent 输入标准化去重复字符、统一标点、去口头语气词。 # 连续重复字符压缩适合处理键盘 chatter # 注意对中文叠词可能误伤需要按业务调整 text re.sub(r(.)\1{2,}, r\1, text) # 全角转半角基础版实现 text text.replace(, ,).replace(。, .).replace(, ?).replace(, !) # 常见语音口头语 text re.sub(r嗯|额|那个|就是, , text) return text.strip() raw 嗯帮我把文件移到 /tmp/logss就是那个文件 print(normalize_agent_input(raw))这种管道不是万能的但能挡住一批低质量输入。关键是要在离线数据集上反复验证清洗规则不会误伤正常指令。第二为高风险操作增加确认。输入扰动再清洗也没法保证 100% 正确尤其是语义反转类型的错误。Agent 在执行删除、发送、转账、修改权限这类动作前应该把解析出的关键参数回显给用户让用户确认一次。这个确认成本远低于错误操作后的恢复成本。第三Agent 内部要做参数校验。如果 Agent 要调用的工具函数有明确类型和取值枚举不要直接把 LLM 输出转成参数要先做类型校验。比如日期字段必须是 YYYY-MM-DD 格式路径字段必须指向允许访问的目录收件人字段必须在通讯录白名单内。输入扰动就算骗过了 LLM也会被参数校验拦下来。第四日志要记录输入侧原始内容不能只记录“清洗后的文本”。否则用户反馈“我说的是周三Agent 执行成了周日”时你根本没法确认是 ASR 错了还是模型理解错了。7. 自动化回归测试与扰动注入实验平台如果要把这个研究方向落地成 Agent 产品的质量保障能力可以搭一套输入扰动回归测试平台。核心思路是准备基准任务集 → 注入扰动 → 调用 Agent → 记录结果 → 对比基线指标。下面是一个简化版的批量评估脚本框架import json import requests import random TASKS [ {id: T001, prompt: 查询上海周三的天气, expected_action: weather_query, expected_params: {city: 上海, date: 周三}}, {id: T002, prompt: 删除 /tmp/old.log 文件, expected_action: file_delete, expected_params: {path: /tmp/old.log}}, ] def inject_perturbation(text: str, level: str) - str: if level none: return text if level low: return inject_keyboard_chatter(text, repeat_prob0.03) if level high: return inject_keyboard_chatter(text, repeat_prob0.08) return text def call_agent(prompt: str, api_url: str) - dict: 调用 Agent 服务接口。实际请求结构以你的后端为准。 resp requests.post(api_url, json{prompt: prompt, task_type: tool_call}, timeout120) resp.raise_for_status() return resp.json() def evaluate(level: str, api_url: str, repeat: int 3): results [] for task in TASKS: for i in range(repeat): noisy_prompt inject_perturbation(task[prompt], level) try: output call_agent(noisy_prompt, api_url) # 这里需要根据实际 Agent 响应结构解析 action 和 params action_ok output.get(action) task[expected_action] params_ok output.get(params) task[expected_params] results.append({ task_id: task[id], level: level, success: action_ok and params_ok, output: output, }) except Exception as exc: results.append({ task_id: task[id], level: level, success: False, error: str(exc), }) return results if __name__ __main__: random.seed(7) api_url http://127.0.0.1:8000/agent for level in [none, low, high]: result evaluate(level, api_url) ok sum(1 for r in result if r[success]) print(flevel{level}, success{ok}/{len(result)})这套框架有几个注意点。一是接口路径和请求体必须按你自己的 Agent 服务调整上面只是通用模板二是每次实验要固定扰动种子确保不同模型版本之间对比有效三是批量跑完要保存完整结果 JSON包括失败样本的输入、输出和错误信息方便后续定位。还可以用 pynput 或 PyAutoGUI 模拟真实键盘事件配合输入延迟和重复按键做端到端测试。这种测试更接近真实环境但执行速度慢适合小样本回归不适合大批量评测。8. 性能观察输入侧延迟与 Token 成本这个研究方向还会牵出一个工程问题输入扰动不仅影响正确率还影响延迟和成本。语音链路天然会引入 ASR 延迟。本地 ASR 通常需要几百毫秒到几秒云端 ASR 还多一次网络往返。键盘输入理论上延迟更低但如果输入法有复杂的联想和纠错也可能在用户端造成等待。对 Agent 来说输入侧延迟会直接叠加到整体响应时间上。Token 成本也不一样。语音转写文本通常包含更多口语化内容长度更长键盘输入如果产生重复字符清洗前也会浪费 Token。输入扰动导致 Agent 多轮纠偏时Token 消耗会进一步上升。从研究的角度看可以统计同一个任务集在 clean 和 noisy 两种输入下的平均 Token 差值这部分多出来的成本就是“扰动税”。观察资源占用时建议在 Agent 服务端记录三个时间戳收到输入文本的时间、第一次工具调用的时间、最终响应时间。再结合输入日志里原始文本和清洗后文本的长度就能估算输入扰动对性能和成本的实际影响。9. 常见问题与排查方法问题现象可能原因排查方式解决方案语音输入后 Agent 执行了错误动作ASR 识别错误未被清洗查看输入日志原始转录文本增加同音字纠错和关键动作二次确认键盘输入出现重复字符键盘 chatter 抖动用 HID 事件测试工具观察按键事件系统层加键盘抖动过滤文本层做去重清洗蓝牙键盘输入时字符丢失蓝牙唤醒丢包或干扰查看系统事件日志尝试固件更新输入回显确认关键指令核对Agent 多轮后偏离任务输入扰动被逐轮放大对比第一轮和最终轮状态增加中间状态校验和任务快照批量评估结果不可复现未固定随机种子或扰动脚本版本检查实验配置固定 random seed记录扰动代码版本清洗规则误伤正常指令去重或语气词规则过强检查误伤样本用离线数据集验证清洗规则按业务调优比较隐蔽的坑是“清洗规则误伤”。比如中文里的叠词“看看”“试试”如果被重复字符压缩规则处理可能变成“看”“试”语义虽然没变但语气变了。所以清洗管道的规则要在业务数据集上做回归不能只看几个样例就上线。10. 最佳实践与使用建议先小步试跑。不要一上来就在全部任务集上跑高扰动等级先用 20 条指令、低扰动等级验证测试框架本身是否可靠。保留一套最小可复现配置。固定任务集、固定扰动种子、固定模型温度这些元信息要随实验结果一起保存。模型文件、测试数据、扰动脚本、输出结果分目录管理。建议按实验日期和模型版本建子目录避免结果互相覆盖。批量任务要加日志和失败重试。Agent 接口偶发超时很正常测试脚本要能区分“接口失败”和“任务执行失败”。涉及人脸、声音、用户输入数据时必须确认授权和隐私合规。语音输入数据包含用户生物特征键盘输入可能包含密码和敏感内容采集和存储都要做脱敏和访问控制。高风险操作要做人工确认。删除、发送、支付、权限变更类工具调用无论输入多干净都要保留确认环节。11. 总结这个研究方向最值得尝试的点是把“打字还是语音”从个人偏好问题变成了一个可以测量、可以优化、可以在工程上拦截的输入质量问题。比起继续争论哪种输入更好更实际的做法是先在自己的 Agent 里跑一遍 clean 输入和扰动输入的对比看看任务完成率掉了多少再决定投入多少资源做输入清洗和回显确认。最先应该验证的功能是“工具调用参数错误率”。用 50 条指令分别跑干净输入、键盘扰动输入、ASR 扰动输入对比工具调用的 action 和 params 正确率。只要参数错误率明显上升就说明你的 Agent 输入侧存在真实风险。最容易踩的坑是用真实 ASR 模型做扰动注入时扰动不可控最后说不清结果是模型问题还是 ASR 问题。建议先用规则扰动定位 Agent 的薄弱点再用真实 ASR 模型做端到端验证。后续可以继续扩展的方向很多多语言输入扰动、Agent 多轮轨迹级评测、工具参数约束自动校验、以及“混合输入模式”下的交互设计。如果你正在做 Agent 应用这个课题值得跟进。