一、GPT‑6 Astra 来了，AIGC已来？
OpenAI 刚把 GPT-6 Astra 掏出来，一堆人又开始喊"AIGC已来"。
按官方模型说明的说法，Astra 主打复杂推理、写代码、搞研究、写文档，还能用 Computer Use、MCP、Shell 这些工具。说白了，给它一个环境，它既能调接口，也能直接上手点软件。
对开发者来说，最爽的就是一句话扔过去，它直接给你把活干完。
"帮我整理这些记录，创建几个待办，再生成一份报告。"
如果 Agent 能打开软件、看懂页面、把内容填进去，再检查一遍结果，这句话真可能变成整个流程的入口。
但真到干活的时候，大家只关心一件事：到底要等多久？
一个能找到按钮、却得反反复复看界面的助手，和一个直接调接口把活干完的助手，体验天差地别。前者像是在表演"我会点鼠标"，后者才真让你觉得"省时间了"。
今天就想聊聊：要是老靠截图识别去干活，它为啥容易被一轮一轮交互拖死，为啥在标准活儿上就是干不过直接调业务接口。
二、慢，不只发生在"识别图像"这一步
1. 一次点击背后，还有一整轮交互
纯视觉操作通常需要经过这样的循环：
text
获取截图 → 理解页面 → 决定动作 → 执行操作
↑ ↓
└──────── 观察新的页面状态 ──────────┘看清楚没？点一下，背后是一整套循环。
这其实就是 Computer Use 的老套路（官方说明）：模型看一眼屏幕，想一想要干嘛，动手，然后环境再把新截图甩给它。一个调用确实能塞好几个动作，不是每点一次都要重新想，但页面一变，或者它自己没底，还是得再瞅一眼。
所以别一慢就怪图像识别，真问题比这大。
截图要时间，传数据要时间，模型想事儿要时间，工具执行、页面加载、确认结果，哪个不要时间？有些活儿系统能重叠着干，但整条链上的依赖关系，不会凭空消失。
粗略看，一个串行流程的耗时可以写成：
text
任务耗时 ≈ 各轮观察、推理、执行与等待耗时之和
+ 异常恢复耗时优化识别速度，顶多省一小块；砍掉几轮交互，可能整个等待直接没了。
2. 模型再牛，也得等页面蹦出来
假设我们要在一个后台创建任务，并把负责人设为张三。
点"新建"之前，编辑弹窗还不存在；输入负责人关键词之前，候选人列表还没加载；点保存之后，也可能要等服务端返回校验结果。
这些步骤有前后依赖。模型可以提前规划，但没法提前知道还没出现的页面到底长啥样。
界面老实点，工具也支持批量，那 Agent 能一口气干好几步。可一旦有动态菜单、异步加载、表单校验这些玩意儿，它就得停下来看结果。
模型越强，顶多少纠结几下；软件本身那套点击流程，一步都省不掉。
3. 最拖时间的，往往是补救
理想很丰满：按钮在它该在的地方，输入框焦点也对，网络也没抽风，那确实顺。
现实呢？你还没输完页面就重排了，保存按钮被弹窗挡了，或者"张三"有俩。
Agent 必须重新观察、判断状态、修正选择，再继续执行。有时候还得确认上一次保存到底成没成，免得重复建两条。
所以别拿一次演示说事儿。你真正感受到的，是包括重试、恢复、等待在内的总时间。偶尔卡一下，节奏就全乱了。
三、干一样的活，为啥调接口就轻松多了
还是"创建任务"这个例子。
走界面，路数可能是这样：
text
打开项目 → 进入任务列表 → 点击新建 → 填写标题
→ 搜索负责人 → 选择人员 → 设置日期 → 保存 → 检查结果如果软件已经给了完整的业务接口，那模型可以把需求转成结构化参数，直接交给工具提交：
json
{
"tool": "create_task",
"arguments": {
"project_id": "project_demo",
"title": "检查首页加载性能",
"assignee_id": "user_demo",
"due_date": "2026-09-15"
}
}这串只是示意参数，不是哪个平台的真实接口，也不是完整的 MCP 报文。
但有个前提躲不掉：项目 ID 和负责人 ID 得先定下来。用户只说"张三"，还得先查人、消歧义。接口不会自动替你把需求弄明白。
即便如此，业务接口还是能省掉打开弹窗、找输入框、展开日期选择器这些界面步骤，直接收下干活需要的数据。
说白了，接口站得更高，步子更少。模型还是那个 Astra，只是走的路不一样了。
四、### 别神化 MCP，工具设计才是命门
1. MCP 就是个协议，又不是阿拉丁神灯
MCP 是让模型接外部工具的统一方式（MCP 与连接器官方说明）。工具背后可以连业务 API、本地程序，甚至浏览器自动化。
所以"上了 MCP 就一定快"这话，趁早别信。
如果一个 MCP 服务只暴露这些工具：
text
take_screenshot()
click(x, y)
type_text(text)模型还是得看页面、找位置、点点点。把视觉操作套个 MCP 壳，交互成本一点没少。
如果它暴露的是这些：
text
search_users(keyword)
create_task(project_id, title, assignee_id)
get_task(task_id)模型才有机会直接干业务活儿。
咱们比的，就是"低层界面动作"和"高层业务操作"的差距。
2. 工具拆得太碎，也会把快路走慢
假设创建任务要分别调五个工具：设置标题、设置负责人、设置日期、保存草稿、提交任务，而且每步都交回模型重新决策。
这路数就算不碰截图，也可能明显延迟。
高频操作最好给参数齐全、行为明确的业务工具；能批量的给批量入口；返回结果也别含糊，省得模型还得来回查"到底成没成"。
不过，合并操作也有边界。需要用户拍板的事、必须分阶段校验的流程，不能为了速度直接跳过去。
3. 返回结构化数据是好，但别以为万事大吉
创建任务的工具可以返回任务 ID、保存后的字段和执行状态。比起盯着页面上一条成功提示，这些数据更好核对，也方便后续操作。
但"请求成功"不等于"业务完成"。有的接口只是收了个异步作业，有的返回部分成功，有的写入后还得等后续处理。
写操作还得防重复。网络超时了直接重试，可能就建了两条一模一样的记录；得靠幂等键、明确状态或再查一次，Agent 才知道下一步咋走。
接口路线通常更可控，但稳定性还是得靠工程设计兜底。
五、那为啥还要搞视觉操作？
可能有人要问：既然业务接口效率高，还费劲搞 Computer Use 干嘛？
因为大量软件根本没给 Agent 留接口。
旧版桌面应用、企业内部系统、临时搭的后台，还有开放能力不全的网站，可能只剩图形界面这一个入口。给每款软件都开发、维护专用连接器，也得花时间。
这种时候，视觉操作可能让原本没法自动化的流程跑起来。它少的是接入障碍，你才能在"等它慢慢点"和"自己动手"之间做选择。
还有些任务，结果本身就得靠眼睛判断。比如检查图表有没有挡字、页面在窄屏下有没有错位、PPT 排版协不协调。接口能把数据写进去，但没法证明最终显示效果没问题。
所以更合理的安排是：能用接口生成或改内容，就在关键节点看一眼实际效果；接口没覆盖的功能，再上界面操作。
视觉在这儿给到的信息，恰好是结构化数据里扒不出来的。
六、想让 Agent 快点？先让它少折腾
1. 动手前先选对路子
有现成业务接口的活，优先走 API、CLI 或者对应的 MCP 工具。
网页上的结构化表单，如果没有业务接口，但能读 DOM 或无障碍树，也可以按元素名称、角色和属性操作。这仍然在走界面流程，但通常比纯坐标定位靠谱。
只有视觉信息才能表达的内容，或者没法结构化访问的界面，再交给截图识别。
| 任务 | 可优先尝试的入口 | 主要原因 |
|---|---|---|
| 批量创建、查询业务记录 | API、CLI 或业务型 MCP 工具 | 可减少界面步骤并支持批量处理 |
| 填写有语义标签的网页表单 | DOM 或无障碍树 | 可以直接定位输入框和按钮 |
| 操作缺少接口的传统软件 | 视觉操作 | 界面可能是唯一可用入口 |
| 检查排版、图表与画布效果 | 视觉观察结合专用工具 | 最终效果需要看实际呈现 |
这表就是个思路，具体还得看工具质量、权限和任务要求。
2. 别啥失败都甩给视觉操作
业务接口缺功能，切到界面操作可能有帮助；接口返回权限不足，换到界面通常也解决不了授权问题。
保存结果不确定时，应该先确认状态，而不是立马在页面再点一次"保存"。
切工具之前，先搞清失败原因，既能省时间，也能少重复操作。
3. 模型只用在刀刃上
字段格式转换、结果数量检查、明确的状态轮询，很多都可以交给程序。独立查询可以并行跑，稳定动作在工具允许范围内可以合并。
碰上含糊需求、跨系统选择、异常恢复，再让模型上。
少一次没必要的模型往返，比你让模型下次回答快几个字值钱多了。
4. 快不快，看整件事啥时候干完
想验证视觉路线和接口路线的差距，就得在相同任务、相同初始状态、相近权限下多跑几次，记录：
- 从收到需求到结果验证完成的总耗时。
- 任务成功率，以及失败后的恢复情况。
- 模型调用轮次、工具调用次数和重试次数。
- Token、工具服务这些实际成本。
除了看中位数，也得瞄一眼 P95 这种慢任务耗时。光拿一次最顺的演示说事，根本反映不了日常。
反正，别被"会看屏幕"的演示唬住。真想让它干活快，少绕路才是正经。
七、结语
对了，本文章由GPT‑6 Astra自动生成并发布