这周看了个叫 Munder Difflin 的东西——用 agent harness 在浏览器里开一家全是自己克隆人的办公室。好玩，真的很会演示。但说句实话，计算机使用类 Agent 现在的状态是：demo 比生产成熟一个数量级。随便一场录屏都能让外行觉得"电脑自己会干活了"，丢到真实用户手里就不是这么回事了——非标准界面、随时变化的网页、权限弹窗横在中间，成功率立刻跳水。我的判断标准很简单：界面会变的，先别上；成功与否需要人来判断的，先别上。唯一没争议的用途，是那些没有 API、只有屏幕的老系统。
这周的 demo 照旧惊艳，但也照旧只在录屏里成立
Munder Difflin 的噱头是让一堆 agent 在模拟办公室里各司其职。拆开看，每个角色背后都是一条编排好的提示词加几个工具调用。它把任务做成了可控环境：界面固定，步骤固定，成功信号清晰。但真实桌面不是这样。按钮会跳动，弹窗会迟到，Windows 更新会半夜弹出来把焦点抢走。
而且模型对截图的"理解"本质上是概率性的——同一张像素布局，跑两遍可能得出两个不同的坐标。传统自动化脚本失败是确定的：元素没找到就是没找到，立刻报错。GUI agent 失败是随机的：这次点对了，下次点偏了，再下次弹窗挡住直接点到了别的按钮。随机失败在运维里是最难受的那种失败，因为它没法靠重试解决，重试只会放大错误。
ArXiv 这周有篇从电脑操作记录里提取任务模型的论文，正好戳在这个痛点上。作者用被动录制的屏幕加键鼠序列去归纳人实际怎么做事的。为什么要做这个？因为 agent 在训练数据里看到的都是干净的成功轨迹，而真实的人类操作充满犹豫、回退、试探。这个 gap 不补，agent 永远只会在 benchmark 里显得聪明。
别指望跨任务迁移，学到的技能比你想的脆
另一篇讲技能迁移的论文说，agent 从完成任务里归纳出来的技能，复用的时候可能不稳定，甚至会反过来伤害性能。我完全信。GUI agent 学到的"技能"往往跟具体截图特征绑死——换个主题、换台机器分辨率不同，技能就失效。更糟的是它不会主动承认失效，只会按错误的记忆继续点下去，直到把某个不该点的配置给改了。
这周 HN 上那个 AGENTS.md 的 issue 也侧面印证了问题。Claude Code 的用户在求一个"给 agent 看的文档"规范。连纯文本 CLI 这种界面极其简单的环境，都还在摸索怎么给 agent 描述项目约定、构建命令、代码风格——GUI 那边连契约的影子都没有，谈什么成熟。MidTool 那篇做工具使用的中途训练，本质也是在给模型补基础能力。补基础能力，说明基础能力还不够。
能上的窄场景，标准只有两条
我自己给"能不能上生产"划的线就两条：界面会不会变，成功信号能不能机器判断。两条都满足的，上。满足不了任何一条的，先别碰。
具体点说：固定界面的重复操作，比如每天批量录入、从固定表格导出报表、走完一个固定审批流程，这种可以。成功信号要明确到代码能判断——文件生成了、页面跳转到了目标页、返回了明确报错。凡是"做完得人肉看一眼对不对"的任务，就让 agent 跑半程，把最脏的重复劳动吃掉，最后一步留给人类点确认。事故半径最小化。
怎么测自己的场景能不能上？别信官方 demo。自己挑 30 个真实任务样本，连着跑几天，看成功率、看失败模式的分布。如果失败集中在某个已知步骤，那还能修；如果失败是散开的、每次都不重样，那就是界面复杂度的问题，不是调参能解决的。
但也有个它独享的场面：没有 API 的老系统
反面观点也得说透。银行的核心系统、政府部门的老审批平台、一堆内网 ERP，很多根本没有 API，或者有但拿不到权限。系统是十几年前的技术栈写的，文档早就丢了，联系人早离职了。这种环境下，能"看着屏幕操作"的 agent 是唯一现实的解法——不是因为它可靠，是因为没有别的路。
我的态度是：别指望它全自动。把它当成一个"视力还行但容易走神的新员工"，让它干 80% 的链路，每一步都留出人工确认的口子。按我现在看，这跑得通。也许 6 个月后回头看会被打脸，但至少到目前为止，我没找到比这更好的路子。