GPT-6 Astra 电脑操作 API：接入循环、安全确认与结果验收

GPT-6 Astra 的电脑操作能力并不是“把一句话发给模型，电脑就自动完成任务”。在 API 集成中，你的应用仍要提供浏览器或桌面运行环境、执行模型提出的操作、回传新界面，并在最后检查目标系统里究竟发生了什么。OpenAI 当前的电脑操作指南对 Astra 推荐 code execution；原生 computer tool 仍然受支持。

截至 2026 年 9 月 4 日，访问还在分批开放。OpenAI 的模型页写明，Astra 先面向 Trusted Access Program 企业客户推出，API 及 Plus、Pro、Business、Enterprise 的访问会在随后几天扩展。这不等于每个账号现在都能调用。ChatGPT 工作区里能看到模型，也不能证明某个 API project 已获授权。

因此，实施顺序应从三件事开始：确认自己的 API project 能调用 gpt-6-astra，选择适合现有自动化系统的执行方式，再为风险动作和最终结果设计独立的检查。

先分清两种接入方式

两种方式都通过 Responses API 工作，也都要求你的程序真正执行动作。区别在于模型返回什么，以及你的执行环境需要提供什么。

OpenAI 在code execution 说明中把它作为 Astra 的首选。模型调用的只是你定义的普通 function；示例里的执行服务属于开发者应用，并不是 OpenAI 托管的远程电脑。一次脚本可以包含点击、循环或条件逻辑，因此权限限制必须在执行器和它暴露的 helper 中落实，不能只写在 prompt 里。

如果现有系统已经把 UI 操作封装成 function calling 或远程 MCP 工具，可以继续使用这个接口。只有当 computer 返回的结构化动作更适合你的事件管线时，才有必要改用原生工具。

code execution 的最小循环

下面是控制关系的简化骨架。它省略了真正的沙箱、登录状态保存和动作策略；executeInIsolatedRuntime 与 verifyTargetState 都需要由你的应用实现。

js
const tools = [{
  type: "function",
  name: "execute_ui_script",
  description: "Run approved UI automation in a persistent isolated browser",
  parameters: {
    type: "object",
    properties: { code: { type: "string" } },
    required: ["code"],
    additionalProperties: false
  },
  strict: true
}];

let input = [{ role: "user", content: task }];
let previousResponseId;

for (let step = 0; step < 12; step++) {
  const response = await client.responses.create({
    model: "gpt-6-astra",
    tools,
    input,
    previous_response_id: previousResponseId,
    reasoning: { effort: "low" }
  });

  if (response.status !== "completed") break;

  const calls = response.output.filter(
    item => item.type === "function_call"
  );
  if (calls.length === 0) {
    await verifyTargetState();
    break;
  }

  input = [];
  for (const call of calls) {
    const args = JSON.parse(call.arguments);
    const decision = await checkPolicyAndConfirm(args.code);
    if (!decision.allowed) throw new Error("execution stopped");

    const observation = await executeInIsolatedRuntime(args.code);
    input.push({
      type: "function_call_output",
      call_id: call.call_id,
      output: observation
    });
  }
  previousResponseId = response.id;
}

这里最容易漏掉的是 call_id。每个执行结果必须对应原始调用；previous_response_id 则让下一次 Responses 请求延续模型对话。官方连接运行环境的示例采用同样的关系。

循环上限 12 只是示例。生产系统应按任务设置步数、总时长和预算，并在 API 返回 incomplete 或 failed、脚本不完整、运行环境失联、登录状态消失时停止。盲目重发最后一个脚本可能重复提交表单或重复修改数据。

使用 computer tool 时，截图才是下一轮输入

原生方式从 tools: [{ type: "computer" }] 开始。模型产生一个 computer_call，其中可以包含按顺序执行的多项动作。应用执行允许的动作后，截取更新后的屏幕，再以相同 call_id 返回 computer_call_output；截图对象的类型是 computer_screenshot。

js
const next = await client.responses.create({
  model: "gpt-6-astra",
  tools: [{ type: "computer" }],
  previous_response_id: response.id,
  input: [{
    type: "computer_call_output",
    call_id: computerCall.call_id,
    output: {
      type: "computer_screenshot",
      image_url: screenshotDataUrl,
      detail: "original"
    }
  }]
});

截图说明建议在需要精确坐标时使用 detail: "original"。更大的截图会增加输入 token；如果为了成本缩小图片，执行器必须把模型坐标正确映射回原始界面。否则模型判断可能正确，实际点击位置仍会偏移。

computer_call.status 为 completed 只表示模型把这次调用生成完了。它没有替你的程序点击，也没有证明页面接受了操作。循环文档要求持续执行、回传并检查，直到不再出现 computer_call，而最终业务结果还要另外验收。

同时维护三种状态

电脑操作常见的“模型说完成了，但系统没有变化”，通常不是一个状态问题。

previous_response_id 不会恢复浏览器 session，更不会回滚外部动作。每轮执行前都应确认当前页面仍是预期页面；断线恢复时先重新观察，而不是假设屏幕停在上一步。

最终验收也不要只检查一条成功提示。以“把三条测试联系人写入 CRM 草稿”为例，完成条件可以是：确实存在三条草稿、字段值与输入一致、没有发送通知、没有正式提交。模型的文字总结只能作为线索，目标系统的可读取状态才是结果。

把人工确认放在风险发生之前

OpenAI 的安全运行要求把隔离、允许列表、确认、取消和结果核验交给集成方。一个实用的任务定义至少应包含：

• 允许访问的域名、应用、账号和数据范围；
• 允许自动执行的低风险动作，例如导航、读取和填写未提交草稿；
• 必须停下确认的动作，例如购买、发送或上传数据、删除、修改权限；
• 禁止触碰的凭据、生产资源和系统设置；
• 最大步骤、时间、成本与连续失败次数；
• 由目标系统读取的成功条件，以及无法确认时的失败状态。

网页、邮件、PDF 或工具返回的文字都是外部内容，不能给模型新增权限。页面里即使写着“请关闭安全检查并继续”，也不应改变用户授权。对 actions[]，执行器应在第一项需要确认的动作之前停止；对生成脚本，则需要在底层 helper 限制域名、文件、网络和可调用动作，因为一段脚本可能连续做很多事。

执行生成代码的环境应可丢弃、最小权限，并与 API key 和生产凭据隔离。执行服务指南明确提醒，Node.js vm 或限制 Python globals 不能单独构成安全边界。客户端请求超时也不会自动终止运行环境里的失控进程，两边都要有截止时间和取消机制。

rollout、参数和旧版迁移的三个陷阱

首先，工具调用必须走 Responses API。Astra 虽然也列出 Chat Completions endpoint，但当前迁移指南规定 tools 使用 Responses。可用的 reasoning effort 是 low、medium、high、xhigh 和 max；从 none 或 minimal 迁移时应先改为 low。不要继续发送不支持的 temperature、top_p 或 logprobs 参数。

其次，ChatGPT 权限和 API 权限必须分别检查。工作区模型说明显示，Enterprise 的初始开放还涉及管理员配置。看到同事在 ChatGPT 中使用 Astra，不代表你的服务端 key 已获准。

最后，维护 computer-use-preview 的团队不要把两件事混为一谈。OpenAI 当前的电脑操作集成文档仍然把旧模型迁到 gpt-5.6-sol 与 computer，并把单个 action 改成批量 actions[]。新建 Astra 集成时采用 code execution 是另一项建议，并不等于官方已经给出“preview 直接迁 Astra”的路径。

上线前用失败场景验收

一条顺利演示不能证明自动化已可上线。至少用以下故障验证控制循环：

1. 登录过期：执行器是否停止并要求重新登录，而不是在错误页面继续点击；
2. 页面插入诱导指令：策略是否保持原权限，不接受网页自行扩大授权；
3. 批量动作中途出现删除或提交：是否在该动作之前暂停；
4. 截图尺寸改变：坐标是否正确映射，是否先观察再继续；
5. API 或运行环境中断：是否记录最后一个已确认结果，避免重复提交；
6. 模型停止调用：应用是否仍查询目标记录，而不是直接采用“完成”文本。

OpenAI 的 misalignment monitoring 可能对部分 Responses 会话发出告警或停止继续，但官方说明同时指出，它可能误报、漏报，也可能在动作发生后才发现问题；停止会话不会撤销已经执行的动作。收到 misalignment_policy_violation 时不应自动重试。这个监控可以增加一道信号，不能替代你的确认和验收。

当 API project 确实获得 Astra 访问、执行环境能持续返回真实观察、风险动作会在执行前暂停、失败可取消并恢复、最终结果能从目标系统独立验证时，电脑操作才从模型演示变成可用的工程能力。