OpenAI Agents API 在 2026 年 9 月 29 日的发布说明里新增了 computer use：加上一个工具声明和一个 openai_hosted 环境配置，你的智能体就能操作一个由 OpenAI 云端托管的真实浏览器，去访问网站、点按钮、填表单、截图。你不用再自己搭浏览器沙箱、会话持久化和上下文压缩那一整套东西。
但有个坑必须先说清楚：「批准一次来源」不等于「批准这一次操作」。你批准了 example.com，智能体在这个站点里加购下单、删数据都不会再回来问你。护栏不在 API 里，在你的代码里。这是本文要讲的核心。
computer use 到底加了什么
在此之前，OpenAI 的浏览器操作能力只在面向消费者的 Operator 产品里。开发者想用，只能自己在外面搭：起一个无头浏览器容器、维护会话状态、处理长任务上下文溢出、断线恢复。 Agents API 把这套东西收进了托管环境里。
接入配置是三段：
| 配置项 | 值 | 作用 |
|---|---|---|
tools | { "type": "computer_use" } | 给智能体挂上屏幕操作能力，可加 include_screenshots 拿回截图 |
environment | type: "openai_hosted"、desktop.enabled: true | 启用云端桌面，浏览器跑在 OpenAI 的隔离环境里 |
model | 目前需要 gpt-6-astra | computer use 对模型有要求，不是随便一个模型都支持 |
结构大致长这样（字段以官方文档为准）：
{
"agent": {
"model": "gpt-6-astra",
"tools": [
{ "type": "computer_use", "include_screenshots": true }
]
},
"environment": {
"type": "openai_hosted",
"desktop": { "enabled": true },
"network": { "access": "enabled" }
}
}之后 network.access 这一层是可收紧的——如果你只让它跑内网站点或有明确白名单的域名，把网络访问关掉或按域名限制，比在应用层做判断更可靠。
两种审批请求，务必分清
智能体第一次访问某个域名时，会给你抛一个 agent.session.requires_action，里面带 computer_use_approval_request 条目。你要处理的是两类东西，处理方式完全不同：
1. 来源访问审批（browser_origin_access）
把「 origin + 理由」展示给用户，用户点同意/拒绝/取消，你回一个决定。这是整站一次性授权，批了之后这个 origin 内不再回问。
curl "https://api.openai.com/v1/agents/sessions/$SESSION_ID/events" \
-H "OpenAI-Beta: agents=v1" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"events": [
{
"type": "agent.session.input.computer_use_approval_request_result",
"request_id": "REQUEST_ID",
"response": { "type": "browser_origin_access", "decision": "approve" }
}
]
}'2. 浏览器登录（browser_authentication）
需要账号密码时，智能体会把表单字段（fields）和登录选项（options）回传给你，你拿到用户在你自己界面里输入的凭据，再 action: "submit" 回去。凭据不经过模型输入，也不会留在会话历史里。
maxRetries: 0，curl 用 --retry 0），否则会出现模型连着几次重复提交凭据的尴尬场面。为什么「一次授权」这件事要认真对待
官方文档里有一句很直白的话：来源审批并不强制在每个具体动作前再次确认。这不是 bug，是设计——不然智能体每点一下都要人批，自动化就废了。代价是：你批准的是一整个站点的操作权限。
官方给的建议是「把托管浏览器限制在无法执行购买或破坏性变更的资源上」，并把所有网站内容当作不可信输入。这两条建议都对，但都靠人执行。翻译成工程语言，我一般这么做：
- 站点分级。把目标站点分成「只读」和「可写」两档。只读档（文档站、后台只读面板、公开数据库）走自动审批；可写档（电商、后台管理、财务）一律要求人工确认，或干脆不接。
- 网络层收紧。不要图省事直接
network.access: "enabled"全开。按network的域名白名单配置，并记得把重定向后的域名也算进去——否则会出现「批了 A 域名、跳转到 B 域名」的绕过。 - 关掉凭据自动重试。
maxRetries: 0，避免重复提交密码；同时确认你的代码在收到action: "cancel"时能干净地终止会话而不是重开。 - 日志脱敏。开了
include_screenshots之后，截图里可能有账号信息、订单金额、后台数据。别把 base64 图片直接打进日志，脱敏规则要在写日志之前生效。
关于「优先给智能体 API 而不是 UI 」这个原则，我认为是官方文档里最有价值的一句建议。如果被操作的系统是你自己的，那就把它包成 MCP server 暴露出去——工具是类型化的、结果可校验、不依赖脆弱的视觉流程。只有当目标系统压根没有 API（第三方后台、老旧内部系统）时，浏览器操作才是合理选项。这条判断标准能挡掉大部分不必要的浏览器自动化。
成本：三个计费表同时跳
Agents API 没有独立的一条价格线，是三块同时计：
| 项目 | 量级 | 备注 |
|---|---|---|
| 模型 token | computer use 需 gpt-6-astra，约 $10 输入 / $50 输出（每百万 token） | 比 gpt-6.1-sol（$2 / $10）贵一个量级 |
| 计算机沙箱 | 约 $0.03 – $1.92 / 20 分钟 | 跨度很大，取决于实际占用 |
| 上下文膨胀 | 没有单独条目，但会乘进 token | 这是真正的成本陷阱 |
重点说第三行。工具返回结果会重新喂进下一轮提示词，一个没开上下文压缩的会话跑到第十轮，单次模型调用可能已经在付 10 万以上输入 token 的钱。所以上下文压缩要从第一天就开——用自动模式或者自己设阈值，别等账单出来才反应。托管环境帮你做了长任务的上下文管理和断线恢复，但账单不会帮你省。
什么情况下该用 Agents API，什么情况下不该
该用：长时间运行、多步骤、沙箱里跑的自主任务（批量数据采集核对、跨系统巡检、无人值守的表单流程），你不想自己维护浏览器沙箱和会话状态。
不该用：普通聊天问答、单次工具调用、或者你还在从 Assistants API 迁移。 Assistants API 已在 2026 年 8 月 26 日下线，正确路径是 Responses API + Conversations API 。把 Agents API 当成 Assistants 的直接替代品，架构从第一天就错了。
相关阅读
如果你在搭智能体体系，下面几篇可能用得上：
- OpenAI Agents API 是什么——托管编排的整体定位，先看这篇再决定要不要上 computer use 。
- GPT-6.1 Sol 定价与 multi-agent——如果你的任务不需要浏览器，$2/$10 的模型比 astra 划算得多。
- AI 浏览器自动化工具怎么选——自建方案与现成方案的取舍。
- 编码智能体沙箱隔离——「把浏览器当成把笔记本交给陌生人」这个比喻的技术含义。
- 智能体护栏实现——审批流、限流、审计日志的通用工程做法。
computer use 和 Playwright 自动化怎么选？
支持 computer use 的模型只有 gpt-6-astra 吗？
为什么我的智能体在登录环节反复提交密码？
maxRetries: 0（curl 用 --retry 0），并且认证请求五分钟后就会过期，需要在应用侧做超时清理。会话返回 202 是不是就代表操作成功了？
computer_use_call 这类条目看实际动作和输出。另外记得：202 的响应是异步的，网络策略要按域名白名单配置，重定向目标也要包含在内。截图里包含用户账号数据，可以直接存吗？
include_screenshots 打开后返回的是 base64 JPEG，可能带有账号、订单、财务信息。要落盘就先做脱敏，或者只保留任务结束后的最后一张状态图，中间过程截图丢弃。
评论 (0)