UUID 不是随便生成的：版本、冲突和 5 个使用误区
2026/10/1 8:32:08
GPT-6.1 Sol 与 Agents API 计算机使用实战：托管智能体的架构与权限边界
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-29：https://openai.com/index/devday-2026-recap/