Appearance
Browser / Computer Use 如何进入 Coding Agent Workspace
前置:Coding Agent 如何形成闭环:Planner / Generator / Evaluator、Recovery 与 Artifact Contract
核心问题:Browser/Computer Use 进入 Workspace 后,哪些交互可以自动执行,哪些必须受 capability、sandbox 或 approval 约束?
Browser 是更不确定的“手”
API Tool 往往有稳定 schema:
text
create_issue(title, body) → issue_idGUI 操作却可能是:
text
observe screenshot/DOM
→ decide target
→ click/type/scroll
→ page changes asynchronously
→ observe again按钮位置、弹窗、登录状态和页面版本都可能变化,所以一次 action 后必须获得新的 Observation,不能把“模型说自己点击了”当事实。
Browser Session 属于 Workspace Execution Environment
需要明确 session identity:
text
browser_session_id
workspace/run binding
allowed origins
credential/profile reference
current page / window set
artifact/screenshot refs长任务恢复时,原浏览器 session 可能已经不存在。Runtime 应能够:重新建立 session → 导航到可验证位置 → reconciliation 当前外部状态,而不是序列化一个 Python browser object 进 checkpoint。
能用 API 时优先 API,必须用 GUI 时缩小 Capability
GUI capability 通常比 API 粗:一个浏览器可能访问整个企业站点,而 Tool API 只允许一个资源。因此需要限制:
- allowed origins/domains;
- download/upload directory;
- popup/new-window policy;
- clipboard;
- credential autofill;
- destructive action approval;
- action rate/step budget。
模型获得“Browser Tool”不应自动等于“可以访问任意 URL + 任意凭证”。
高风险动作要有 Before/After Evidence
例如发布生产版本:
text
before: page identity + target environment + change summary
→ approval
→ click Publish
→ observe confirmation / deployment id
→ verify via API/page status
→ durable ToolExecutionResult截图可作为证据,但图片本身不是唯一事实来源;能读取结构化 DOM/API response 时优先保存稳定 identifier。
Prompt Injection 在 Browser 场景更直接
网页本身是不可信内容。页面可能要求 Agent 下载文件、粘贴 secret、进入另一个域或忽略当前目标。Browser observation 必须按外部 Tool Result 处理,不能升级权限。
Failure Modes
点击坐标后直接记录成功
处理: action 后重新 observe,并用页面/结构化状态验证目标真的变化。
Browser Profile 携带过多长期凭证
处理: 独立 session、最小 credential、origin allowlist;敏感 Tool 仍走 approval/capability policy。
如何验证
故意改变按钮位置、弹出确认框、让页面返回诱导文本,并模拟 browser session 丢失;Run 应能失败安全、重新定位或要求人工,而不是继续盲点坐标。
自测
- Browser/Computer Use 产生屏幕点击等真实副作用时,为什么不能只按“视觉模型输出”来判定动作已经完成?
- 网页环境会动态变化。执行点击前后应记录哪些 Observation,才能区分“点击成功”和“页面状态符合目标”?