GPT-6.1 Sol 与 Agents API 计算机使用实战托管智能体的架构与权限边界 本文唯一事实来源为 OpenAI 官方页面《DevDay 2026 回顾》2026-09-29。文中关于模型定位、成本口径、开放范围和 Agents API 能力的内容均归因于该官方页面。代码只使用通用伪代码与数据结构不虚构 API 参数、具体单价、基准分数或未确认的开放范围。OpenAI 在 DevDay 2026 回顾中发布了多项更新。对做工程落地的团队来说最值得拆开看的是两件事GPT-6.1 Sol 的定位以及 Agents API 新增的计算机使用computer use能力。本文不讲发布会热闹只讲工程团队真正要决策的部分选型依据、架构分层、权限与审计边界以及上线前的验收清单。—## 一、先看清 GPT-6.1 Sol 的官方定位官方页面对 GPT-6.1 Sol 的表述集中在三点- 它是 GPT-6 Sol 的一次重大升级- 在智能体编程agentic coding、计算机使用computer use和专业工作方面表现突出- 它以仅为 Astra 标准输入和输出 Token 价格五分之一的费用提供接近 Astra 的智能水平。开放范围方面官方写明GPT-6.1 Sol 现已面向所有 API、Plus、Pro、Business、Enterprise 和 Edu 用户开放。这里有一个容易踩的坑官方给的是相对成本口径约五分之一不是可以直接写进成本表的单价。工程团队做预算时应该按自己账户的实际计费页取数不要把发布会里的相对倍数当成报价单。另外官方页面提到GPT-6.1 Sol 超高速档位即将推出当前已推出的是 GPT-6 Astra 超高速。把即将当成可用是另一个常见误读。### 选型判断| 你的任务特征 | 建议方向 || — | — || 简单文本改写、短分类 | 先用更低成本模型跑通 || 多步工具调用、代码变更、专业交付 | GPT-6.1 Sol 进入候选队列 || 需要最高智能且成本不敏感 | 仍以 Astra 级模型为主 || 强调极低延迟 | 等超高速档位明确可用后再评估 |—## 二、Agents API 的计算机使用官方到底给了什么官方页面对 Agents API 的描述是开发者可以以托管方式使用 Codex 执行框架。职责划分很清楚text你的应用负责定义任务、连接工具和数据、展示进度OpenAI 负责运行底层系统官方列出的能力包括- 多智能体multi-agent- 工具搜索tool search- 工具调用tool calling- 上下文压缩context compaction- 新增的计算机使用能力。可用途径方面官方写明可通过 API 使用500 美元 Pro 方案订阅用户和符合条件的 Enterprise 客户也可在 Codex 和 ChatGPT 工作中使用。这意味着工程团队不必从零搭建 Agent 运行时、工具路由和上下文管理这一整套基础设施。但托管不等于免治理——恰恰相反底层越托管你越要定义清楚边界。—## 三、架构分层把托管能力放进自己的控制面一个稳妥的做法是把系统分成四层每一层都明确归属。textL1 任务层你的代码 任务定义、输入范围、输出格式、完成标准、禁止事项L2 工具层你的代码 托管能力 工具白名单、参数校验、只读/可写/需审批分级L3 执行层托管运行时 多智能体协作、工具搜索、工具调用、上下文压缩L4 治理层你的代码 身份与权限、审计日志、证据留存、失败与人工升级关键原则L1 和 L4 必须留在自己手里。托管的是执行能力不是责任归属。### 工具清单应该长什么样不要只列工具名要连权限级别一起写json{ tool: internal_ticket_api, scope: read_only, data_class: internal, rate_limit: per_task_capped, requires_human_approval: false, audit: { log_request: true, log_response_digest: true, log_actor_identity: true }}写可写或需审批的工具时要单独标记因为它们是风险集中点。json{ tool: crm_write, scope: write, requires_human_approval: true, approval_reason: 外部客户可见, reversible: false}—## 四、计算机使用带来的三类新风险Agent 能操作电脑听起来只是能力升级但对工程团队来说它同时带来了三类新风险。### 1. 权限放大风险Agent 拿到的是一个真实环境真实浏览器、真实后台、真实文件系统。它能点的按钮就是它可能点错的按钮。控制手段- 用独立身份运行 Agent不要复用员工账号- 按最小权限分配工具- 生产环境的写操作默认走审批。### 2. 副作用不可逆风险读操作出错可以重试写操作出错往往不可撤销。官方支持的能力不区分这两类是你的架构要区分。控制手段- 把工具硬性分为只读 / 可回滚写 / 不可回滚写- 不可回滚写默认不进自动执行路径- 保留变更前后快照。### 3. 审计断链风险多智能体协作时一个任务可能跨越多个 Agent、多次工具调用。如果不主动记录事后很难还原谁在什么时候基于什么证据做了什么决定。控制手段- 统一任务 ID 贯穿整个执行链- 每个步骤记录输入摘要、工具、结果摘要和耗时- 人工审批记录单独留存。—## 五、一条可落地的执行链路把官方能力对应到工程实现可以从这条链路开始text任务定义 ↓工具清单 权限级别 ↓身份与权限确认 ↓执行多智能体 / 工具搜索 / 工具调用 / 上下文压缩 ↓证据留存截图、日志、diff、文件路径 ↓验收检查 ↓人工升级按规则触发每一步都要有明确产物| 阶段 | 产物 || — | — || 任务定义 | 目标、输入范围、输出格式、禁止事项 || 工具清单 | 工具名、权限级别、数据等级、审批要求 || 权限确认 | 运行身份、本次授权范围、有效期 || 执行 | 步骤记录、工具调用日志、中间结果摘要 || 证据 | 截图、链接、diff、变更记录、失败原因 || 验收 | 逐项检查结果、未通过项与原因 || 升级 | 触发原因、已收集上下文、建议下一步 |—## 六、上下文压缩在长链路任务里的作用官方把上下文压缩context compaction列为 Agents API 支持的能力之一。对长链路任务这一点比听上去更重要。当一次任务跨越几十次工具调用时如果每一步的完整输出都堆在上下文里成本和稳定性都会快速恶化。压缩的价值在于保留决策所需的关键信息丢弃冗余过程。工程上要配合三件事1. 明确哪些信息不允许被压缩掉身份、授权范围、已确认事实、未完成承诺2. 压缩后仍要能追溯到原始证据保留引用不保留全文3. 关键节点做显式快照不依赖压缩结果。—## 七、Codex Cloud 与代码审查在流程中的位置官方页面还提到两个和开发流程直接相关的能力。### Codex Cloud支持按需运行 Codex在电脑上、通过手机远程操作或从任意设备在云端运行。官方提到可复用的开发环境能让任务快速启动并为团队提供采用已批准设置和权限的共享配置。工程含义环境一致性比提示词更容易被忽视。给团队准备已批准设置的共享环境能减少我这边能跑、你那边跑不了这类问题。### 代码审查官方介绍 ChatGPT 桌面应用中的代码审查体验可以浏览摘要、深入查看差异、向 Codex 询问潜在问题自动审查可以让 Codex 在云端完成初审。官方写明支持 GitHub Pull Request 和 GitLab 合并请求。工程含义把它当成第一层检查不是最终负责人。责任人仍然要签最终合并决定。如果你希望把这些步骤、工具和证据放进一个可复盘的界面里统一管理agent.space 这类 Agent 工作台可以作为一个观察入口重点不在于多接几个模型而在于让任务、工具、权限和证据在同一条链路上可见。—## 八、上线前验收清单在把 Agent 接进真实系统前逐项确认text[ ] 任务目标、输入范围、输出格式已写清[ ] 工具清单包含权限级别与数据等级[ ] Agent 使用独立身份不复用员工账号[ ] 写操作按可回滚 / 不可回滚分类[ ] 不可回滚写操作默认走人工审批[ ] 执行过程留存截图、日志或变更记录[ ] 失败、冲突、越权场景有明确升级规则[ ] 发布、删除、转账、生产变更不默认自动执行[ ] 上下文压缩不会丢掉身份与授权信息[ ] 有明确的最终复核责任人—## 九、成本与评测别用发布会的相对倍数做预算官方给出的约五分之一是相对成本口径。做预算时建议按下面的方式取数text单次任务成本 ≈ (输入 token / 1M × 输入单价) (缓存输入 token / 1M × 缓存单价) (输出 token / 1M × 输出单价) 工具调用与外部服务费用 失败重试成本 人工复核时间成本评测时至少记录- 首次通过率- 平均修正轮数- 工具调用失败率- 人工拦截次数- 单任务总成本含人工时间。只看模型变便宜了很容易得出错误结论真正的成本大头往往在重试和人工复核。—## 结语GPT-6.1 Sol 与 Agents API 的计算机使用能力把 Agent 从生成答案推进到按任务调用工具、操作真实环境、留下可审计证据。托管底层让工程团队少建一套基础设施但任务定义、权限分级、证据留存和人工升级这四件事仍然必须由团队自己负责。如果你在做 Agent 平台或内部自动化系统可以从一个低风险任务开始跑通整条链路定义任务、列清工具、确认权限、执行、留存证据、按规则升级给人。跑通之后再逐步放开权限和复杂度。唯一核心来源OpenAI 官方页面《DevDay 2026 回顾》2026-09-29https://openai.com/index/devday-2026-recap/