本文是「Agent 开发实践与思考」系列第 12 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示
- 06-03 能看会说的 Agent：语音交互与 Computer Use 这半年（本篇）
给工单工具增加语音入口时，我原以为主要问题是识别率和首包延迟。后来在虚拟机中测试浏览器自动化，发现另一个限制：多数系统假定操作者是人。
人可以查看屏幕、记住刚才操作的位置，并在陌生页面中临时判断；系统因此将许多能力放在菜单、表格、弹窗和登录后的页面中。即使模型能处理图像和语音，要完成「查完数据，填进表格，发给某个人」这样的任务，仍需操作这套面向人的界面。
Computer Use 反映了当前软件的接口限制：Agent 可以理解目标，但许多软件尚未提供供 Agent 调用的操作接口。
语音入口要求任务状态与取消机制
语音有两条常见路线。级联方案是 ASR 转文字、LLM 生成文字、TTS 合成语音；端到端方案则由模型直接接收和输出音频。前者每段都能替换、记录和排查。后者在部分模型中能保留更多语气和停顿信息，也可能更快，但中间转写、工具调用和审计能力取决于具体接口。
我们最后采用级联方案。工单场景需要记录用户原话、转写结果、调用能力时使用的上下文，以及操作是否成功。语音可以作为输入，但业务链路必须可追溯。
流式处理和打断消耗了最多开发时间。ASR 要持续给出中间结果；LLM 的第一个可播报句子要尽早交给 TTS；用户重新说话时，播放器必须清空缓存，并取消正在生成的回复和未提交的动作。
例如，Agent 说「我现在帮你转给一线同学」，用户马上打断：「别转，先问我确认。」如果前端只停止声音，后端仍发出转单请求，问题在于系统将一次对话处理为无状态的文本生成。语音交互使这个问题更早出现。
一次请求需要有身份、任务编号、状态和取消语义。用户可以先用语音发起「把下午冲突的会议整理出来，给改期建议」，系统立即回复「我查完发到手机」，然后在后台继续查询日历、生成草稿和发送通知。用户不必一直留在通话中，任务也不会因短暂网络中断而丢失。
语音是任务入口，并要求系统支持从单轮回答转为执行任务、完成任务，并在必要时向用户请求补充信息。
GUI 在 Agent 执行中的适用范围
我在隔离虚拟机中测试过网页检索填表和操作内部旧后台。基本流程是：截一张图，模型输出点击、输入、滚动操作，执行器操作页面，再截一张图。
大按钮和大输入框通常可以完成操作。困难在于密集表格中相邻的操作项、遮住半边页面的浮层、没有文字的图标，以及灰掉但仍显示在列表中的按钮。模型点不到可以重试；如果点到相邻数据行，可能已经执行了错误操作。
截图的问题也不只是坐标不准。浏览器知道元素是否为按钮、控件是否可编辑、选项是否禁用，这些语义存在于 DOM 和无障碍树中。截图将这些信息压缩为像素后，模型还要推断页面结构。只通过屏幕操作网页会放弃系统已有的结构化接口。
验证也是问题。API 调用可以检查状态码、返回字段和幂等键；命令执行可以检查退出码、输出文件和 diff；屏幕操作通常只能看到一句「提交成功」，还需要判断这个提示是否可信。操作步骤增加后，等待时间、图像调用成本和错误概率都会累积。
GUI 可作为兼容层，不应作为 Agent 的主执行面。
有授权 API 时先调 API；没有 API 但能读 DOM 或无障碍树时，用元素语义定位；两者都没有时，再使用截图、鼠标和键盘。涉及发送、删除、付款、发布或权限变更时，无论使用哪种通道，都要有独立于模型的确认和校验。
这套顺序解释了一个实际现象：许多浏览器自动化 Demo 可以演示多种操作，但进入业务场景后通常只能处理缺少接口的部分。它用于覆盖没有接口的操作，不应用视觉推断替换已有的可靠接口。
现有软件主要面向人而非 Agent
将语音和 GUI 放在一起考察，可以看到软件接口的限制。
当前软件接口大致分为两类。一类供机器使用，包括 API、数据库、消息队列、命令行和文件格式。它们结构化、可组合，也可以自动校验。另一类供人使用，包括网页、App、桌面窗口、表单、菜单和通知。它们用于降低人的学习成本，但将状态、权限和操作路径置于视觉交互中。
过去业务系统优先建设第二类接口是合理的，因为员工和用户是实际操作者。现在 Agent 开始代替人跨系统完成任务，接口缺口随之出现：模型可以理解「导出本月数据并更新分析表」，但数据平台和分析表若都只提供网页，就没有让程序安全表达该动作的入口。
Computer Use 采用了通用的过渡方案：系统只提供人使用的入口时，Agent 暂时以人的操作方式使用系统。该方案可用，但会将每个系统的交互细节、页面变化、登录态和视觉误差转化为 Agent 的处理成本。
面向 Agent 的系统应将已有能力暴露为稳定、范围明确且可验证的操作接口：列出资源、读取状态、提交变更，以及返回机器可读的失败原因。人仍可使用页面；Agent 则无需为同一任务理解页面。
CLI 在 Agent 执行中的作用
命令行是 API 和网页自动化之间的一层接口。
API 是理想方案，但现实中的系统无法立即补齐 API。网页自动化覆盖范围较大，但可靠性和成本较差。CLI 位于两者之间：它比 GUI 更结构化，比专门的 API 更容易临时接入，也适合被模型组合。
上一篇关于 Coding Agent 的文章中，我将「文件系统 + 命令执行」定义为通用 Agent 的最小工作台。当时讨论的是写代码。这个判断也适用于其他任务：在缺少面向 Agent 的接口时，CLI 可以作为通用适配方式。
CLI 的作用来自其输入和输出形式。输入输出是可保存、比较和重放的文本或文件；操作有退出码和标准错误，失败结果不依赖截图判断；多个命令可以组合为脚本；脚本可以被版本管理、审查、测试和复用。CLI 还允许 Agent 在工具缺失时为当前任务编写工具。
例如，旧配置平台只有网页。让模型反复操作页面导出几百条配置，速度慢，也难以确认每次导出的范围。可以先在受限环境中观察请求和页面结构，编写一次性脚本抓取所需数据，导出为 JSON 或 CSV，再用另一个命令校验行数、字段和日期范围。该脚本不一定需要成为正式产品，但可将只能人工操作的页面临时转换为可重复调用、可验证的命令。
这与我在Agent 如何用代码完成推理、校验、适配与展示中讨论的「代码当适配器」相同。平台团队不必预先提供所有工具。只要 Agent 有受控的文件系统、运行环境和命令执行能力，就可以为当前任务生成范围较小的适配器：解析导出文件、包装内部接口、抓取页面、转换数据格式，或生成只读报表。
CLI 不应允许模型任意执行 shell。它适合作为执行面，是因为可以严格约束工作目录白名单、只读凭证、网络出口、命令类别、资源配额、超时和审批。模型提出动作，执行环境决定是否允许。
Agent 需要任务执行环境
只有聊天记录和一组函数调用的 Agent，难以处理持续时间长或步骤较多的任务。它需要任务专用的工作环境。
任务环境可以包含工作目录，用于保存任务输入、下载文件、临时脚本、草稿和结果；受限的进程环境，用于执行命令；任务状态，用于记录已完成步骤和等待项；以及事件入口，用于接收用户通过语音、消息或定时任务发起的补充、修改和取消。
例如，用户晚上说：「把这周客户反馈里反复出现的问题整理出来，明早给我一页。」Agent 可以将原始数据、筛选脚本和来源链接保存到工作目录，先生成草稿，再在早上通知用户。凌晨用户补充「不要融资新闻，重点看招聘和产品更新」时，系统应修改仍在运行的任务条件并重新执行相关步骤；两句自然语言和全部历史对话不应作为重新推断的唯一依据。
用户要求将旧后台的数据导入分析表时，任务环境应保留下载的原文件、转换脚本、写入前后的校验结果和失败日志。需要人工接手时，接手人应能检查这些中间产物。
Agent 的记忆包括聊天历史，但不能只保留聊天历史。历史对话适合保留协商过程；事实、文件、脚本、任务状态和执行记录应保存在工作区和状态库中。模型上下文可以压缩，任务证据应保存在上下文之外。
权限、审批与执行结果校验
接入语音、命令和屏幕操作后，需要区分模型能够执行的动作与系统允许其自主完成的动作。
例如，Agent 从工单中读取客户信息、起草邮件或定位删除按钮时，向外发送信息、直接发送邮件和执行删除仍需相应授权。模型可以理解任务、补全参数和处理含糊输入，权限和审批仍应由业务系统执行。
落地时，需要先确认操作是否留下可核对的结果。发送邮件后应取得发送记录，写入数据后应取得对象版本，网页导出后应检查下载文件。页面显示「成功」或模型声称「已经完成」都不能作为结果。
任务也需要取消机制。用户在语音中更改指令时，应取消未提交动作；用户修改目标时，原计划不应继续执行；发送、删除或修改权限等步骤，系统应等待确认。这样可以将责任保留给相应责任人。
临时脚本也需要管理。一次性取数完成后可以删除；脚本开始反复使用时，应纳入版本管理并走 review。高频、关键任务如果长期依赖网页自动化或临时脚本，说明系统缺少正式接口。
结论
工单语音入口最终上线的方案由流式 ASR、流式 TTS 和已有 Agent 逻辑组成。用户最直接的反馈集中于打断后系统是否停止，以及更换指令后是否能继续处理任务。这些反馈比参数指标更能反映 Agent 在真实工作流中的要求。
屏幕操作的测试也得到类似结论。视觉能力使 Agent 可以操作没有接口的旧环境；将其作为主路径时，Agent 仍需以人的方式操作不适合机器调用的系统。
应为 Agent 提供受控执行环境：用文件保存事实，用 CLI 和脚本处理临时需求，用结构化接口执行稳定操作，并以 GUI 覆盖没有接口的部分。系统改造可以逐步进行。Agent 可以先在该环境中编排现有能力，并将反复出现的人工界面任务识别为后续应建设的机器接口。
