api_gui_cli_world全部约 80 分钟
11B
Agent 怎样操作世界：API、GUI、CLI 与真实环境
参考：来源 F · 第 23、26 章
学完你能做到
- 理解 Agent-Computer Interface 的感知-行动循环
- 为任务选择 API、浏览器、桌面或命令行
- 设计确认、验证与故障恢复
浏览器和桌面工具只是环境，不是 Agent。真正的 Agent 还要看懂当前状态、决定下一步、执行动作、确认界面是否真的变化，并在弹窗、超时或页面改版后恢复。这套桥接模型与计算机的机制叫 。
| 接口 | 优点 | 弱点 | 优先使用场景 |
|---|---|---|---|
| API/函数 | 结构稳定、可校验、速度快 | 需要服务提供接口 | 能使用结构化接口时优先 |
| CLI | 文本清楚、可脚本化、适合开发 | 命令可能破坏系统 | 代码、文件、服务器和批处理 |
| 浏览器/GUI | 无需专门 API，覆盖人能操作的软件 | 像素和布局易变化，状态难确认 | 没有 API 的遗留系统或跨应用流程 |
| 摄像头/麦克风/设备 | 能感知物理环境 | 噪声、延迟、隐私与安全风险最高 | 现场辅助、机器人、实时多模态任务 |
接口选择的实用顺序
- 能用结构化 API，就不要依赖屏幕像素。
- 开发与文件任务优先 CLI，但要放进并限制可执行命令。
- 没有接口时才使用 GUI，并同时读取 DOM、可访问性树或视觉信息。
- 跨越信任边界、写入外部系统或触及真实世界时，提高确认和验证等级。
环境接口设计
15 分钟- 为“替学生预约考试”拆出查询、填写、支付三个阶段。
- 为每个阶段选择 API/GUI/人工，并说明原因。
- 列出页面改版、验证码、重复提交时的恢复策略。
案例推演：同一个订票任务为何 API、DOM 和视觉操作风险不同
航空公司 A 有稳定 API，B 只有网页 DOM，C 只能通过远程桌面视觉操作。三种接口的可观察性、动作确定性和验证方法不同。
本节追问：什么时候应优先结构化接口，什么时候视觉操作才合理？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 选择接口 | 按 API、结构化 DOM、视觉坐标的顺序评估 | 选择理由包含稳定性与可验证性 | 有网页就默认截图点击 |
| 定位对象 | 使用稳定 ID、语义选择器或视觉锚点 | 动作前能唯一识别目标 | 固定坐标点击易受布局变化影响 |
| 执行确认 | 在提交、付款等边界前展示对象与后果 | 用户确认绑定具体航班和金额 | 确认后页面变化仍沿用旧授权 |
| 验证结果 | 读取订单号、状态和服务端记录 | 动作成功有独立观察 | 按钮消失就认为订票成功 |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
让视觉模型连续快速点击直到页面变化
实际上
可观察症状：误点击、重复提交和状态漂移难以发现。
更可靠的修复：每个动作采用“观察—定位—执行—再观察”，高风险边界重新确认。
案例工作坊 · 建议真正动手完成
25 分钟- 比较 API、DOM、视觉三种接口的失败模式。
- 为付款按钮写动作前后验证清单。
- 设计页面改版后的安全停止条件。
查看参考答案
接口越结构化，通常越容易校验和重放；视觉交互提供更广覆盖，但需要更强观察、定位和动作验证。选择依据是可用性与风险，而非炫技。
迁移检查：换一个场景还会不会
已有稳定 API 时通常优先 API 的核心原因是？