GPT-5.6与ChatGPT工作：设计生产级智能体控制平面

引言

2026年7月发布的GPT-5.6很容易被视作一次普通的模型更新。Sol是旗舰路线，Terra是平衡选项，而Luna则是更快、成本更低的层级。官方发布内容涵盖了编程、专业工作、科学、计算机使用和安全领域的广泛评估。

这种解读虽然准确，但并不完整。

理解GPT-5.6更有用的方式是将其视为一种操作性产品。OpenAI开放了多项智能体开发者此前需要隐藏于自定义编排代码中的决策：分配多少推理资源、何时使用并行智能体、如何协调工具而无需将每个中间结果返回给模型，以及如何根据任务的价值和风险匹配模型能力。

与此同时，ChatGPT Work将Codex相关的长时运行任务模型扩展到了更广泛的工作空间，涵盖文档、电子表格、演示文稿、网站、连接的应用、浏览器操作、计算机使用以及定时任务。

这些能力带来了更大的工程责任。为更强的模型提供更多工具并不能自动创造可靠的数字工作者——它创造的是一个能更长时间运行、跨越更广数据边界并做出更具影响力变更的系统。

生产级设计必须在运行开始前回答以下问题：

• 谁授权了该任务？
• 智能体可以读取哪些内容？
• 它可以修改哪些内容？
• 哪些操作需要审批？
• 它可以使用多少时间和预算？
• 有哪些证据可以证明结果正确？
• 当出现问题时，团队如何停止或恢复工作流？

本指南为使用GPT-5.6、ChatGPT Work、Codex或自定义智能体构建的团队提供了一种控制平面方法。它将模型能力与操作权限分离，并提供具体场景、路由规则、评估指南和可复用的策略模板。

核心要点

• GPT-5.6最适合被视为能力和计算菜单。Sol、Terra和Luna是模型路线，而推理力度和多智能体执行则是独立的预算控制。
• ChatGPT Work将委托单位从单个答案转变为可跨越文件、连接应用、浏览器操作、计算机使用和定时任务的完整成果。
• 生产级智能体需要围绕模型构建控制平面：任务分类、限定身份、工具策略、审批关卡、可观测性、评估、预算和恢复机制。
• 公开基准有助于发现候选模型，但私有任务集对生产部署决策至关重要。
• 团队应从可逆、可审查的工作流开始，在收集充分证据后才扩展自主权。

GPT-5.6实际带来了哪些变化

GPT-5.6在ChatGPT、Codex和API中提供了三个能力层级：

• Sol： 最高能力路线。
• Terra： 适用于日常工作的平衡路线。
• Luna： 最快且最经济实惠的路线。

OpenAI将这些名称描述为持久的能力层级，而非带有时间戳的临时模型名称。这一区分对生产系统很有价值。

诸如“将平衡层级用于常规库维护”这类策略，可以在未来快照变更时保持稳定。当可复现性至关重要时，团队可以单独锁定一个确切的快照。这比将模型标识符分散在提示词、脚本、任务队列和环境变量中更为清晰。

推理开销与多智能体执行

GPT-5.6 还增加了更显式的计算控制。

max 给予单一模型路线更多时间进行推理、探索替代方案、运行检查并修正结果。ultra 则跨并行工作流协调多个智能体。

这是两种不同的控制方式：

• 更多推理允许单一路线进行更长时间的调查和验证。
• 多智能体执行将额外计算投入到并行工作流中，随后综合其结果。

一项任务可能受益于其中一种、两种或两种都不适用。并行执行并非总是更好，尤其是在子任务共享同一不确定假设或需要相同的受限凭证时。

程序化工具调用

OpenAI 将程序化工具调用描述为一种方式，让模型编写并执行轻量级程序，这些程序可以协调工具、处理中间结果，并决定哪些信息应返回给模型。

这可以减少重复的上下文传输。不是将每个数据库行、浏览器响应或工具结果都返回给模型，而是可以由一个内存程序先过滤和聚合数据。

这种效率伴随着操作上的权衡。更多逻辑转移到了执行层，这意味着团队需要为这些中间步骤制定清晰的跟踪、限制和数据处理规则。

GPT-5.6 版本还在 Responses API 中引入了多智能体测试版。因此，并行执行正在成为 API 级别的能力，而不仅仅是应用端的编排模式。

定价是路由选择的输入参数

发布时，官方价格如下：

这些价格是路由决策的输入参数，而非决策本身。

一个更便宜的模型，如果它会反复重试、读取不必要的上下文，或者产生被审查者拒绝的工作，那么每个可接受结果的成本可能更高。一个更强的模型，如果它能通过一次小规模且经过验证的修改就完成任务，那么实际成本可能更低。

正确的指标不仅仅是每 Token 成本，而是每个可接受结果的平均成本。

ChatGPT Work 改变了委托单位

ChatGPT Work 被呈现为一个能够跨应用程序和文件工作的智能体，可以持续运行数小时，将目标分解为更小的步骤，并创建完成的工件。

OpenAI 表示 Codex 技术内置于该产品中，但其目标范围比软件工程更广。示例工作流程包括：

• 预算分析
• 营销活动简报
• 潜在客户审核
• 产品发布检查
• 竞争研究
• 文档
• 电子表格
• 演示文稿
• 网站

重要的变化在于委托的单位。

一个普通的聊天轮次是在寻求一个答案。一个 Work 任务则是在寻求一个结果。

这个结果可能需要系统做到：

1. 阅读多个资料。
2. 在有新信息时改变方向。

信息出现。
3. 创建多个工件。
4. 等待人工审批。
5. 在用户离开期间通过计划任务继续执行。
6. 使用已连接的应用、嵌入式浏览器或桌面端计算机操作。

OpenAI 正在整合产品界面。聊天、工作和 Codex 功能现在整合到更新后的桌面体验中，而浏览器功能则迁移到更广泛的产品环境中。

这形成了一个涵盖本地文件、网页、连接服务、浏览器操作及长期运行任务的统一权限边界。

因此，企业控制措施与界面同等重要。管理员连接管理、合规性功能和审查机制都指向同一个问题：代理必须以正确的身份、最小必要的上下文、可见的操作效果以及可恢复的路径来执行操作。

即使团队构建的是自定义 API 代理而非直接使用 ChatGPT Work，Work 也是一个有用的参考运营模型。它揭示了当助手成为持久工作者时会出现的问题：

• 状态
• 工具身份
• 审批
• 调度
• 工件
• 治理

术语理解：模型、框架、代理与控制平面

模型

模型将输入上下文映射到输出和工具决策。它具备能力、限制、定价、延迟和安全行为。

Sol、Terra 和 Luna 是模型层级。模型本身不决定组织权限。

代理框架

代理框架是围绕模型的软件环境。它选择上下文、暴露工具、执行命令、存储状态、处理失败重试，并决定运行何时完成。

即使模型和任务保持不变，改变框架也可能显著影响成本和可靠性。一个反复发送大上下文窗口的框架可能比一个过滤中间结果的框架成本高得多。

因此，除非同时指定框架，否则“模型性能”是不完整的。

代理

代理结合了：

• 一个模型
• 一个目标
• 工具
• 状态
• 一个框架

代理可以执行多个步骤并响应工具结果。长期运行的代理可能创建子任务或子代理，但并行工作者不会自动形成安全的多代理系统。它们仍然共享预算、权限和最终验收决策。

控制平面

控制平面是管理代理运行的策略与操作层。

它：

• 分类任务
• 选择路线
• 发放限定范围的凭证
• 强制执行审批
• 记录追踪
• 评估结果
• 停止工作
• 回滚操作

执行平面负责执行任务。将两者分离，团队可以在不改变谁有权部署生产代码或发送外部消息的前提下更换模型。

审批关口

审批关口是代理在未获得授权人员或确定性策略批准前无法通过的决策点。

审批应关联到具体行动及其证据。

一个有效的审批请求是：

批准使用附件中的收件人列表和已审核内容，向这 412 位收件人发送此最终版邮件。

一个无效的审批请求是：

批准营销任务。

验收测试

验收测试是证明代理输出符合要求的证据。

请求的结果是完整的。

可能是：

• 单元测试
• 架构验证
• 已渲染文档审查
• 对账总计
• 人工评分标准
• 安全扫描
• 代码所有者批准

仅仅由模型声明"完成"是一种状态声称，而非验收测试。

生产代理控制平面

一个实用的生产控制平面需承担八项职责。

1. 任务分类

分类应涵盖：

• 领域
• 影响范围
• 可逆性
• 数据敏感度
• 模糊性
• 预期价值
• 验证强度

"更新常见问题草稿"与"修改认证策略"虽都涉及文本编辑，但归属不同处理路径。

2. 选择模型与投入预算

成本最低且符合资格的路径是合理默认选项，但资格条件必须优先于价格考量。

示例：

• Luna：用于低风险信息提取
• Terra：配合强源校验的中等分析需求
• Sol：架构评审、安全审查或复杂仓库诊断
• Ultra：仅当任务可清晰拆解且额外并行成本合理时使用

3. 创建受限于作用域的执行身份

代理应获取仅限任务所需仓库、文件夹、应用程序或记录的短期凭证。

不应仅因便捷性而直接继承开发者完整的浏览器会话。

执行身份必须在日志中可见，以便团队追溯所有外部操作。

4. 应用工具策略

以下能力应相互隔离：

• 读取
• 写入
• 发送
• 购买
• 删除
• 部署
• 修改权限

能搜索邮箱的连接器不应自动具备发送邮件能力；可检查仓库的GitHub集成不应自动合并拉取请求。

5. 强制执行审批与确定性检查

审批关卡应出现在关键操作前，并展示简洁的影响预览与证据。

对于软件，证据可包含：

• 差异对比
• 单元测试
• 类型检查
• 安全扫描
• 部署方案

对于财务，证据可包含：

• 来源总额
• 对账校验
• 公式验证
• 差异检查

6. 记录事件轨迹

追踪信息应包括：

• 目标变更
• 来源检索
• 工具调用
• 审批记录
• 制品输出
• 错误详情
• 重试原因
• Token消耗
• 消耗时长
• 最终状态

简洁摘要适用于日常运维，但不足以支撑事故复盘。

7. 执行预算与中止条件

实用的限制包括：

• Token预算
• 工具调用预算
• 运行时长限制
• 重试次数限制
• 费用上限
• 文件数量限制
• 差异大小限制

中止表现不佳或陷入循环的运行并非自主性失败，而是策略的成功应用。

8. 接管恢复工作

恢复措施可包括：

• 恢复文件
• 回退提交
• 撤销凭证
• 取消定时任务
• 删除草稿
• 创建事故工单

若系统无法在执行前说明恢复方案，则该任务尚不适合无人值守运行。

依据任务形态路由至Sol、Terra与Luna

模型路由规则应足够明确，方便工程师、产品经理与安全审查人员解读。

下表为

起点，而非通用排名。

最后一列最为重要。

模型能力不得增加权限。

从Luna切换到Sol不能静默增加写入权限。提升推理力度不能将草稿变为已批准的外部消息。Ultra不能创建多个共享无限制生产凭证的工作进程。

基于证据的升级机制

Luna路线在以下情况可升级：

• 置信度低于阈值。
• 无法提取必填字段。
• 源材料存在冲突。
• 验证失败。

Terra编码任务在以下情况可升级：

• 两次有限尝试后仍有未解释的失败测试。
• 变更跨越安全边界。
• Diff差异超出预期文件数量。

当需求冲突或仅剩不可逆操作时，Sol路线应暂停并请求人工介入。

降级同样有用

一旦Sol生成计划，Terra或Luna可在严格检查下执行重复性子任务。

强模型可审查样本而非处理每个条目。这能分离判断与批量处理，并可能大幅降低成本。

权限架构与审批边界

权限系统应从动词开始构建。

读取
搜索
创建草稿
修改
发送
合并
部署
删除
购买
授予访问权限

这些动词具有不同后果。

许多产品集成将多个操作放在一个宽泛的OAuth作用域下。因此控制平面可能需要一个应用侧代理来暴露更精细的操作。

将动词绑定到资源

"读取Google Drive"对许多工作流来说过于宽泛。

更精细的规则可能是：

在UTC时间18:00前，可读取Q3规划文件夹和已批准的品牌模板文件夹。

对于代码仓库，访问权限可能限制为禁用网络连接的单个工作树。对于数据库，只读副本或受控视图通常比生产凭证更安全。

附加条件

示例：

• 可自动创建邮件草稿，但发送需要审批。
• 可自动打开拉取请求，但合并需要CI通过和代码所有者批准。
• 计划任务可刷新仪表板，但

更改数据源需要管理员权限。

保持职责分离

发起变更的代理不应成为正确性的唯一评判者。

有用的证据可以来自：

• 确定性测试运行程序
• 独立的审查模型
• 人类负责人

第二模型不能替代有责任的人类，但可能在行动对外公开前暴露分歧。

提供商的安全保障只是其中一层。他们无法得知用户是否有权测试特定仓库、客户是否批准变更、或生产维护窗口是否开启。

应用授权仍是构建者的责任。

具体场景与故障模式

场景 1：发布就绪代理

一个团队要求 ChatGPT Work 或自定义代理审查：

• 发布计划
• Jira 事项
• 仓库
• 上市文档

所需的产出物是一份列出负责人和阻塞项的 readiness 报告。

代理可以读取所有四个来源并生成报告。未经批准，不得编辑事项状态或向负责人发送消息。

故障模式：过期上下文

报告引用了一个已解决的事项，因为代理使用了缓存文档。

控制平面应要求直接来源链接和时间戳。

故障模式：虚假完成

代理声明发布已就绪，因为检查清单的每一行都有文字。

验收测试应要求每个阻塞性依赖项都有经过验证的负责人、日期和当前状态。

场景 2：编码代理依赖升级

任务是在一个 monorepo 中升级某个库。

Terra 开始工作，因为迁移有文档记录且测试套件很稳健。它创建分支、编辑 lockfile 和受影响包，并运行针对性检查。

编译器错误揭示了身份验证模块中一个未记录的 API 变更。这触发升级到 Sol。

模型变了，但权限不变。

Sol 收到相同的工作树，且没有部署令牌。如果 diff 涉及授权逻辑，策略会添加安全审查关卡。

完成需要：

• 单元测试
• 类型检查
• 依赖审计
• 审查者批准的迁移说明

一个看似可行但跳过这些检查的补丁不会被接受。

场景 3：定时客户反馈工作流

每天早晨，一个代理读取新的支持工单、聚类主题，并更新产品简报。

Luna 可以在敏感字段被移除后对工单进行分类。Terra 可以起草带有来源链接的简报。

二者均不得：

• 关闭工单
• 承诺功能
• 联系客户

故障模式：逐步范围漂移

一条新指令说代理应“同时处理明显的回复”。

这将内部分析工作流变成了外部沟通。

任务分类器应检测新的 send 动词，并要求单独的策略、批准的模板、抽样计划和人类负责人。

场景 4：高价值研究任务

一家公司正在评估三种架构方案。

Sol ultra 为以下方面分配独立工作流：

• 性能
• 安全
• 迁移成本
• 供应商风险

并行执行是合理的，因为工作流之间相互独立。

独立且该决策具有价值。每位工作者都收到源需求及固定预算。

故障模式：相关性证据

所有工作者都引用相同的供应商基准测试，结果看似一致。

综合控制门应衡量来源多样性，标记共有的未经检验的假设，并要求每个选项至少有一个反驳论点。

更多智能体既能改善覆盖范围，也可能轻易放大错误前提。

为什么公开编码基准测试是发现工具

公开基准测试有用，但不应直接决定生产环境的默认选择。

OpenAI对SWE-Bench Pro的审计报告指出，大量公开任务存在以下问题：

• 测试条件过于严苛
• 提示信息不够明确
• 测试覆盖率不足
• 提示内容与隐藏测试的行为不一致

这并不意味着所有公开基准测试都毫无价值。

它意味着分数会继承其数据集和测试框架的测量误差。

公开评估的用途包括：

• 发现候选模型
• 比较已发布的方法
• 识别广泛的能力变化
• 构建内部评估队列

但无法判断模型是否能在特定单一仓库、业务流程或数据环境中做出安全变更。

控制平面应为每次路由决策存储基准测试的溯源信息：

• 数据集版本
• 任务排除项
• 测试框架
• 工具配置
• 推理努力程度
• 试验次数
• 成本假设

缺少这些细节，基准测试分数就会沦为营销话术。

从实际工作中构建私有评估体系

Databricks提供了一个很好的示例，其评估体系基于数百万行代码的代码库。

团队从真实的人类编写的拉取请求中构建任务，涵盖：

• Python
• Go
• TypeScript
• Scala
• Rust
• Java
• Protobuf
• gRPC
• Bazel

选取了近期且具有代表性、包含有效测试的变更，重写任务描述以保留意图但不透露解决方案，并手动审核每个样本。

团队还发现初始设置中存在信息泄露问题。智能体可以从Git历史记录中恢复未来的提交。在评估运行期间，工作树与仓库历史记录完全隔离。

这个细节比最终排名更为重要。它展示了基准测试如何意外地衡量捷径发现能力而非工程能力。

构建小型内部评估集

团队可以从30到60个任务开始。

选择符合以下条件的已采纳历史变更：

• 具有明确的问题描述
• 包含有意义的测试
• 变更范围有限

任务类型应混合包含：

• 常规维护
• 故障诊断
• 跨文件重构
• 前端开发
• 配置修改
• 一至两个安全敏感示例

保留变更前的仓库状态，并隐藏最终补丁。

优先使用确定性测试进行评估

在人工或模型评判之前，先使用确定性测试。

随后增加人工评审环节，涵盖：

• 需求符合度
• 差异质量
• 可维护性
• 不必要的变更

不要让LLM评判完全替代所有正确性检查。评判模型可能会奖励听起来正确但实际错误的答案。

同时评估模型与测试框架

记录以下内容：

• 成功率
• 总成本
• 耗时
• 发送的总上下文
• 工具调用次数
• 重试次数

涉及的文件

• 审阅者修正
• 回滚率

最佳路线是在团队约束条件下产出被接受成果的路线，而非公开分数最高的路线。

可复用智能体策略模板

以下 YAML 是策略产物，而非 API 模式。请根据你的身份提供方、任务队列、连接器、仓库管控和审计系统进行适配。

policy_version: 1
workflow: release_readiness
owner: product-operations

classification:
  impact: medium
  reversibility: high
  data_sensitivity: internal
  ambiguity: medium
  verification: strong

routing:
  default:
    model_tier: terra
    reasoning_effort: medium
  escalate_to_sol_when:
    - conflicting_sources
    - unresolved_blocker_after_2_attempts
    - security_boundary_detected
  ultra:
    allowed: false

budget:
  max_wall_minutes: 45
  max_tool_calls: 120
  max_retries_per_step: 2
  max_estimated_usd: 12

access:
  jira:
    verbs: [read]
    projects: [NX]
  github:
    verbs: [read]
    repositories: [We0 AI/product]
  drive:
    verbs: [read, create_draft]
    folders: [launch-plans]
  external_send: deny
  deploy: deny
  grant_access: deny

approvals:
  - action: publish_report
    role: product-director
    evidence:
      - source_links_present
      - blockers_have_owner_and_date
      - unresolved_conflicts_listed

acceptance:
  required_checks:
    - schema_valid
    - all_sources_fresh_within_24h
    - no_unattributed_claims
    - human_approval_recorded

recovery:
  on_budget_exceeded: stop_and_notify
  on_tool_error_repeat: stop_and_attach_trace
  on_policy_violation: revoke_credentials_and_open_incident

该模板包含若干刻意设计：

• 升级仅改变能力，不改变权限。
• Ultra 模式默认禁用，除非工作流所有者显式启用。
• 外部发送和部署分别独立拒绝。
• 验收以检查项形式表达，而非模型置信度。
• 恢复机制在执行前已定义。

对于编码工作流，将报告检查替换为：

• 针对性测试
• 类型检查
• 代码规范检查
• 安全扫描
• 差异大小限制
• 代码所有者审阅

对于电子表格工作流，要求：

• 公式验证
• 数据源核对
• 渲染结果检查

控制平面结构保持稳定，仅证据部分变化。

可观测性、预算与恢复

长时间运行的智能体会带来新的可观测性问题。

传统请求日志可能仅显示一次 API 调用，而智能体追踪可能包含数百次决策、工具调用、重试和中间产物。

团队需要两者兼备：

1. 供调查用的完整追踪记录。
2. 供运营用的简洁运行台账。

运行台账字段

实用的台账应包含：

• 稳定运行 ID
• 发起用户
• 策略版本
• 目标
• 模型层级及快照
• 推理投入度
• 子智能体数量
• 工具作用域
• 审批记录
• 成本
• 耗时
• 验收检查项
• 最终产物链接
• 最终状态
• 升级原因

这使得能够回答以下问题：

• Terra 失败后，Sol 是否提升了验收率？
• 哪个工作流消耗的审阅者时间最多？
• 哪个工具导致最多重试？
• 哪条路线产生最高回滚率？

使用

多维预算

仅设定金额上限可能导致廉价模型过长时间循环运行，而仅限制时间又可能放任昂贵的并行任务爆发。实用的预算维度包括：

• 金额
• 实际耗时
• Token消耗量
• 工具调用次数
• 重试次数
• 文件数量
• 变更差异量
• 子代理数量

测试恢复机制

恢复功能应像其他特性一样接受测试。典型测试包括：

1. 在运行过程中移除连接器
2. 确认代理在重试后不会重复执行外部操作
3. 使凭证过期并验证追踪日志能解释故障原因
4. 取消已调度任务并确认后续运行停止
5. 回滚生成的提交并标记相关工件为已替代

事件复盘应区分：

• 模型故障
• 框架故障
• 策略故障
• 工具故障
• 人工审批故障

笼统归咎于"AI"反而掩盖了真正可改进的组件。

采用指南与审核清单

从高频、可量化、可逆的工作流起步。推荐候选：

• 发布就绪报告
• 问题分类
• 文档更新
• 测试失败总结
• 内部研究简报

避免首批部署：

• 外部沟通
• 生产变更
• 支付操作
• 权限授予
• 删除流程

记录人工基线

测量：

• 工作流耗时
• 使用来源
• 错误类型
• 审核员期望的证据

没有基线数据，更快的代理输出可能只是将更多工作转移到修正环节。

影子模式运行

让代理生成工件，同时人工独立完成实际工作流。对比结果并标注故障模式，利用这些运行在提升权限前构建私有评估集。

审核清单

从仅草稿权限迁移至受限写入权限前，请确认：

• 任务定义是否足够明确可供评分？
• 模型层级与推理力度是否按策略选择？
• 升级机制是否在权限范围内运作？
• 每个工具是否具有明确的动词与资源范围？
• 凭证是否短期有效且可追溯至运行实例？
• 所有不可逆或外部可见操作是否设有限制？
• 验收检查是否独立于模型的完成声明？
• 追踪记录是否包含来源、操作、审批、错误与成本？
• 预算是否涵盖金额、时间、重试、工具与影响范围？
• 是否测试过凭证撤销、任务取消与回滚操作？
• 私有评估是否涵盖常见及高风险边界情况？
• 是否有指定负责人对工作流结果负责？

每次仅扩展一个维度。团队可新增数据源但保持仅输出草稿，或增加受限写入权限但维持相同模型与任务。同时更改模型、工具、权限与调度将使回归问题难以定位。

构建者当前应做之事

GPT-5.6与ChatGPT Work表明，代理基础设施正在成为独立产品类别。模型层将持续演变，而持久性工作在于控制平面——它能让

这些模型变更是安全的。

创建路由注册表

为Sol、Terra、Luna以及任何非OpenAI候选模型建立一个小型注册表。

存储内容：

• 资格条件
• 数据政策
• 允许的投入范围
• 成本假设
• 已知故障模式

添加私有评估队列，确保新模型不能仅凭社交媒体印象就成为生产环境默认选项。

添加授权代理

在智能体与关键工具之间放置授权代理。

暴露接口：

• 细粒度动词
• 短期凭证
• 审批钩子
• 幂等键

无论任务始于ChatGPT Work、Codex、自定义应用还是定时后台作业，均保持相同边界。

自主运行前先定义验收标准

能够解释任务验证方式的团队，可以分阶段安全实现自动化。

无法定义验证标准的团队，无论基准测试分数多高，都不应让智能体持续运行数小时。

从结果层面评估成本

按以下维度追踪资金和人工时长：

• 已接受的产物
• 已合并的变更
• 已解决的工单
• 已通过的分析

这有助于协调模型路由、工具链效率和审查人员工作量。

当新一代旗舰模型发布时，团队也能给出有依据的回应。

边界与待解决问题

发布材料中的多项声明仍由供应商自行报告。

跨供应商基准比较使用不同的：

• 测试框架
• 推理设置
• 定价假设
• 工具配置
• 数据集

应将这些声明视为内部测试的假设条件。

程序化工具调用和多智能体执行可减少上下文开销，但当追踪能力薄弱时，也可能使中间逻辑可见性降低。

在监管工作流中使用这些功能前，需验证：

• API记录了哪些内容
• 应用程序日志保留哪些信息
• 敏感中间数据的处理方式
• 工作流是否满足所需保留策略

ChatGPT Work的关联应用和计算机使用功能在扩展权限边界的同时提升实用性。可用性、管理控制和连接器权限可能因套餐和部署方式而异。

产品公告不能替代特定工作区的安全审查。

此外还存在人机协作问题。当智能体持续运行数小时，用户可能批准其未密切观察的工作。更好的摘要虽有帮助，但审批质量取决于能否在决策时刻展示预期效果、不确定性及失败检查。

产品设计必须保护人类注意力，而非简单请求点击操作。

因此，最强模型并非最终架构。

生产质量取决于以下要素的关系：

• 模型
• 工具链
• 策略
• 工具
• 证据
• 责任人

这种关系正是智能体控制平台所要明确表达的。

常见问题

什么是GPT-5.6？

GPT-5.6是OpenAI于2026年7月发布的模型系列，分为Sol、Terra和Luna三个能力层级。Sol代表最高能力路径，Terra平衡能力与成本，Luna优先考虑速度和性价比。

什么是ChatGPT Work？

ChatGPT Work是一个代理工作空间，用于跨文件、应用程序、浏览器操作、计算机使用等场景执行长时间运行的任务。

计划工作。与普通对话回合不同，工作任务围绕完成的成果或产物进行设计。

什么是智能体控制平面？

智能体控制平面是管理智能体运行的政策和操作层。它对任务进行分类，选择模型路由，发放限定范围凭证，应用工具限制，强制执行审批，记录跟踪信息，评估结果，控制预算，并管理恢复。

智能体框架与控制平面有何不同？

框架是组装上下文、暴露工具、存储状态、执行操作和管理重试的软件。控制平面则管理该框架的运行方式，包括权限、路由、预算、审批、评估和恢复。

团队何时应使用 Sol、Terra 或 Luna？

Luna 适用于低风险的提取、分类和格式化任务。Terra 适用于常规的存储库工作、文档生成以及带有严格检查的中等程度分析。Sol 则更适用于模糊诊断、架构设计、安全审查和高价值研究。

切换到 Sol 是否会让智能体获得更多权限？

不会。模型能力和操作权限应保持分离。从 Luna 或 Terra 升级到 Sol 应改变推理能力，而不是工具访问权限、写入权限、部署权限或审批要求。

为什么公有基准测试不足以用于生产环境的选择？

公有基准测试可能包含有缺陷的任务、特定于框架的假设或信息泄露。它们有助于发现候选方案，但需要构建基于真实内部工作的私有评估来衡量成本、可靠性、审核负担以及实际环境中的安全性。

对于长时间运行的智能体应记录什么？

日志应包括目标、模型路由、推理过程、工具调用、来源、审批、错误、重试、令牌使用量、成本、耗时、产物、验证结果、升级原因和最终状态。

相关工具

• ChatGPT：OpenAI 的聊天、工作、连接工具及长时间运行任务的产品界面。
• OpenAI API：使用 GPT-5.6 和 Responses API 构建应用的官方平台。
• Codex：OpenAI 用于存储库工作、软件工程和智能体技能的编码智能体平台。
• 编程工具调用：OpenAI 关于协调工具及通过内存程序处理中间结果的官方指南。
• NIST AI 风险管理框架：用于识别、测量和管理 AI 风险的治理框架。
• Databricks：数据与 AI 平台，其工程团队发布了基于真实存储库变更的私有编码智能体评估。

相关链接

• GPT-5.6 全面上市：OpenAI 官方 GPT-5.6 发布，包含模型层级、能力详情、可用性和定价。
• 预览 GPT-5.6 Sol：OpenAI

Sol 模型的早期技术预览。

• ChatGPT 助力雄心勃勃的工作：OpenAI 官方公告，介绍 ChatGPT Work 及其长期运行的任务模型。
• 编程式工具调用文档：官方开发者文档，关于工具调用的编程式协调。
• 在代码评估中区分信号与噪声：OpenAI 对公共代码基准测试可靠性问题的审计与讨论。
• GPT-5.6 系统卡：OpenAI 为 GPT-5.6 发布的安全与能力评估官方文档。
• Databricks 编码智能体基准测试：基于百万行级代码库中真实拉取请求构建的私有评估。

总结

GPT-5.6 为团队提供了更清晰的能力、成本、推理深度和多智能体执行选项。ChatGPT Work 将这些能力扩展到跨文件、应用、浏览器和定时工作流的持续性任务中。

生产环境的挑战不仅仅是选择最强的模型。团队还需要限定身份、精准的工具权限、审批关卡、独立的验收检查、完整追踪、多维预算、私有评估以及经过验证的恢复机制。

从一个可逆的工作流开始，记录人工基线，在影子模式下运行，并且每次只增加一个维度的权限。

生产级的智能体不仅仅是配备工具的强力模型。它是一个运行在可衡量、可逆且可问责的控制平面内的模型。