For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh/articles/gpt-56-chatgpt-work-agent-control-plane.md.
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在ChatGPT、Codex和API中提供了三个能力层级：
OpenAI将这些名称描述为持久的能力层级，而非带有时间戳的临时模型名称。这一区分对生产系统很有价值。
诸如“将平衡层级用于常规库维护”这类策略，可以在未来快照变更时保持稳定。当可复现性至关重要时，团队可以单独锁定一个确切的快照。这比将模型标识符分散在提示词、脚本、任务队列和环境变量中更为清晰。
GPT-5.6 还增加了更显式的计算控制。
max 给予单一模型路线更多时间进行推理、探索替代方案、运行检查并修正结果。ultra 则跨并行工作流协调多个智能体。
这是两种不同的控制方式：
一项任务可能受益于其中一种、两种或两种都不适用。并行执行并非总是更好，尤其是在子任务共享同一不确定假设或需要相同的受限凭证时。
OpenAI 将程序化工具调用描述为一种方式，让模型编写并执行轻量级程序，这些程序可以协调工具、处理中间结果，并决定哪些信息应返回给模型。
这可以减少重复的上下文传输。不是将每个数据库行、浏览器响应或工具结果都返回给模型，而是可以由一个内存程序先过滤和聚合数据。
这种效率伴随着操作上的权衡。更多逻辑转移到了执行层，这意味着团队需要为这些中间步骤制定清晰的跟踪、限制和数据处理规则。
GPT-5.6 版本还在 Responses API 中引入了多智能体测试版。因此，并行执行正在成为 API 级别的能力，而不仅仅是应用端的编排模式。
发布时，官方价格如下：
| 路线 | 输入价格（每百万 Token） | 输出价格（每百万 Token） |
|---|---|---|
| GPT-5.6 Sol | $5.00 | $30.00 |
| GPT-5.6 Terra | $2.50 | $15.00 |
| GPT-5.6 Luna | $1.00 | $6.00 |
这些价格是路由决策的输入参数，而非决策本身。
一个更便宜的模型，如果它会反复重试、读取不必要的上下文，或者产生被审查者拒绝的工作，那么每个可接受结果的成本可能更高。一个更强的模型，如果它能通过一次小规模且经过验证的修改就完成任务，那么实际成本可能更低。
正确的指标不仅仅是每 Token 成本，而是每个可接受结果的平均成本。
ChatGPT Work 被呈现为一个能够跨应用程序和文件工作的智能体，可以持续运行数小时，将目标分解为更小的步骤，并创建完成的工件。
OpenAI 表示 Codex 技术内置于该产品中，但其目标范围比软件工程更广。示例工作流程包括：
重要的变化在于委托的单位。
一个普通的聊天轮次是在寻求一个答案。一个 Work 任务则是在寻求一个结果。
这个结果可能需要系统做到：
信息出现。
3. 创建多个工件。
4. 等待人工审批。
5. 在用户离开期间通过计划任务继续执行。
6. 使用已连接的应用、嵌入式浏览器或桌面端计算机操作。
OpenAI 正在整合产品界面。聊天、工作和 Codex 功能现在整合到更新后的桌面体验中，而浏览器功能则迁移到更广泛的产品环境中。
这形成了一个涵盖本地文件、网页、连接服务、浏览器操作及长期运行任务的统一权限边界。
因此，企业控制措施与界面同等重要。管理员连接管理、合规性功能和审查机制都指向同一个问题：代理必须以正确的身份、最小必要的上下文、可见的操作效果以及可恢复的路径来执行操作。
即使团队构建的是自定义 API 代理而非直接使用 ChatGPT Work，Work 也是一个有用的参考运营模型。它揭示了当助手成为持久工作者时会出现的问题：
模型将输入上下文映射到输出和工具决策。它具备能力、限制、定价、延迟和安全行为。
Sol、Terra 和 Luna 是模型层级。模型本身不决定组织权限。
代理框架是围绕模型的软件环境。它选择上下文、暴露工具、执行命令、存储状态、处理失败重试，并决定运行何时完成。
即使模型和任务保持不变，改变框架也可能显著影响成本和可靠性。一个反复发送大上下文窗口的框架可能比一个过滤中间结果的框架成本高得多。
因此，除非同时指定框架，否则“模型性能”是不完整的。
代理结合了：
代理可以执行多个步骤并响应工具结果。长期运行的代理可能创建子任务或子代理，但并行工作者不会自动形成安全的多代理系统。它们仍然共享预算、权限和最终验收决策。
控制平面是管理代理运行的策略与操作层。
它：
执行平面负责执行任务。将两者分离，团队可以在不改变谁有权部署生产代码或发送外部消息的前提下更换模型。
审批关口是代理在未获得授权人员或确定性策略批准前无法通过的决策点。
审批应关联到具体行动及其证据。
一个有效的审批请求是：
批准使用附件中的收件人列表和已审核内容，向这 412 位收件人发送此最终版邮件。
一个无效的审批请求是：
批准营销任务。
验收测试是证明代理输出符合要求的证据。
请求的结果是完整的。
可能是：
仅仅由模型声明"完成"是一种状态声称，而非验收测试。
一个实用的生产控制平面需承担八项职责。
分类应涵盖：
"更新常见问题草稿"与"修改认证策略"虽都涉及文本编辑，但归属不同处理路径。
成本最低且符合资格的路径是合理默认选项，但资格条件必须优先于价格考量。
示例：
代理应获取仅限任务所需仓库、文件夹、应用程序或记录的短期凭证。
不应仅因便捷性而直接继承开发者完整的浏览器会话。
执行身份必须在日志中可见，以便团队追溯所有外部操作。
以下能力应相互隔离：
能搜索邮箱的连接器不应自动具备发送邮件能力；可检查仓库的GitHub集成不应自动合并拉取请求。
审批关卡应出现在关键操作前，并展示简洁的影响预览与证据。
对于软件，证据可包含：
对于财务，证据可包含：
追踪信息应包括：
简洁摘要适用于日常运维，但不足以支撑事故复盘。
实用的限制包括：
中止表现不佳或陷入循环的运行并非自主性失败，而是策略的成功应用。
恢复措施可包括：
若系统无法在执行前说明恢复方案，则该任务尚不适合无人值守运行。
模型路由规则应足够明确，方便工程师、产品经理与安全审查人员解读。
下表为
起点，而非通用排名。
| 路线 | 适用任务类型 | 所需证据 | 典型权限 |
|---|---|---|---|
| Luna | 分类、提取、格式化、低风险摘要、窄域代码搜索 | 模式验证、样本审查、来源链接 | 只读或仅草稿 |
| Terra | 常规仓库变更、文档生成、已知工作流、中等分析 | 针对性测试、工件验证、人工抽查 | 限定写入，无不可逆外部操作 |
| Sol | 模糊诊断、跨系统分析、架构工作、安全审查、高价值研究 | 广泛确定性检查、审核者可见的推理依据、来源追溯 | 需明确批准的限定写入 |
Sol max | 困难单线程推理，需更多探索与修正以提升质量 | 检查点、成本上限、最终验证 | 与 Sol 权限相同 |
Sol ultra | 高价值、可并行化任务，含独立工作流 | 每工作流证据、综合审查、总预算上限 | 尽可能使用独立限定身份 |
最后一列最为重要。
模型能力不得增加权限。
从Luna切换到Sol不能静默增加写入权限。提升推理力度不能将草稿变为已批准的外部消息。Ultra不能创建多个共享无限制生产凭证的工作进程。
Luna路线在以下情况可升级：
Terra编码任务在以下情况可升级：
当需求冲突或仅剩不可逆操作时，Sol路线应暂停并请求人工介入。
一旦Sol生成计划，Terra或Luna可在严格检查下执行重复性子任务。
强模型可审查样本而非处理每个条目。这能分离判断与批量处理，并可能大幅降低成本。
权限系统应从动词开始构建。
读取
搜索
创建草稿
修改
发送
合并
部署
删除
购买
授予访问权限
这些动词具有不同后果。
许多产品集成将多个操作放在一个宽泛的OAuth作用域下。因此控制平面可能需要一个应用侧代理来暴露更精细的操作。
"读取Google Drive"对许多工作流来说过于宽泛。
更精细的规则可能是：
在UTC时间18:00前，可读取Q3规划文件夹和已批准的品牌模板文件夹。
对于代码仓库，访问权限可能限制为禁用网络连接的单个工作树。对于数据库，只读副本或受控视图通常比生产凭证更安全。
示例：
更改数据源需要管理员权限。
发起变更的代理不应成为正确性的唯一评判者。
有用的证据可以来自：
第二模型不能替代有责任的人类，但可能在行动对外公开前暴露分歧。
提供商的安全保障只是其中一层。他们无法得知用户是否有权测试特定仓库、客户是否批准变更、或生产维护窗口是否开启。
应用授权仍是构建者的责任。
一个团队要求 ChatGPT Work 或自定义代理审查：
所需的产出物是一份列出负责人和阻塞项的 readiness 报告。
代理可以读取所有四个来源并生成报告。未经批准，不得编辑事项状态或向负责人发送消息。
报告引用了一个已解决的事项，因为代理使用了缓存文档。
控制平面应要求直接来源链接和时间戳。
代理声明发布已就绪，因为检查清单的每一行都有文字。
验收测试应要求每个阻塞性依赖项都有经过验证的负责人、日期和当前状态。
任务是在一个 monorepo 中升级某个库。
Terra 开始工作，因为迁移有文档记录且测试套件很稳健。它创建分支、编辑 lockfile 和受影响包，并运行针对性检查。
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
编译器错误揭示了身份验证模块中一个未记录的 API 变更。这触发升级到 Sol。
模型变了，但权限不变。
Sol 收到相同的工作树，且没有部署令牌。如果 diff 涉及授权逻辑，策略会添加安全审查关卡。
完成需要：
一个看似可行但跳过这些检查的补丁不会被接受。
每天早晨，一个代理读取新的支持工单、聚类主题，并更新产品简报。
Luna 可以在敏感字段被移除后对工单进行分类。Terra 可以起草带有来源链接的简报。
二者均不得：
一条新指令说代理应“同时处理明显的回复”。
这将内部分析工作流变成了外部沟通。
任务分类器应检测新的 send 动词，并要求单独的策略、批准的模板、抽样计划和人类负责人。
一家公司正在评估三种架构方案。
Sol ultra 为以下方面分配独立工作流：
并行执行是合理的，因为工作流之间相互独立。
独立且该决策具有价值。每位工作者都收到源需求及固定预算。
所有工作者都引用相同的供应商基准测试，结果看似一致。
综合控制门应衡量来源多样性，标记共有的未经检验的假设，并要求每个选项至少有一个反驳论点。
更多智能体既能改善覆盖范围，也可能轻易放大错误前提。
公开基准测试有用，但不应直接决定生产环境的默认选择。
OpenAI对SWE-Bench Pro的审计报告指出，大量公开任务存在以下问题：
这并不意味着所有公开基准测试都毫无价值。
它意味着分数会继承其数据集和测试框架的测量误差。
公开评估的用途包括：
但无法判断模型是否能在特定单一仓库、业务流程或数据环境中做出安全变更。
控制平面应为每次路由决策存储基准测试的溯源信息：
缺少这些细节，基准测试分数就会沦为营销话术。
Databricks提供了一个很好的示例，其评估体系基于数百万行代码的代码库。
团队从真实的人类编写的拉取请求中构建任务，涵盖：
选取了近期且具有代表性、包含有效测试的变更，重写任务描述以保留意图但不透露解决方案，并手动审核每个样本。
团队还发现初始设置中存在信息泄露问题。智能体可以从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
该模板包含若干刻意设计：
对于编码工作流，将报告检查替换为：
对于电子表格工作流，要求：
控制平面结构保持稳定，仅证据部分变化。
长时间运行的智能体会带来新的可观测性问题。
传统请求日志可能仅显示一次 API 调用，而智能体追踪可能包含数百次决策、工具调用、重试和中间产物。
团队需要两者兼备：
实用的台账应包含：
这使得能够回答以下问题：
仅设定金额上限可能导致廉价模型过长时间循环运行，而仅限制时间又可能放任昂贵的并行任务爆发。实用的预算维度包括：
恢复功能应像其他特性一样接受测试。典型测试包括：
事件复盘应区分：
笼统归咎于"AI"反而掩盖了真正可改进的组件。
从高频、可量化、可逆的工作流起步。推荐候选：
避免首批部署：
测量：
没有基线数据，更快的代理输出可能只是将更多工作转移到修正环节。
让代理生成工件，同时人工独立完成实际工作流。对比结果并标注故障模式，利用这些运行在提升权限前构建私有评估集。
从仅草稿权限迁移至受限写入权限前，请确认：
每次仅扩展一个维度。团队可新增数据源但保持仅输出草稿，或增加受限写入权限但维持相同模型与任务。同时更改模型、工具、权限与调度将使回归问题难以定位。
GPT-5.6与ChatGPT Work表明，代理基础设施正在成为独立产品类别。模型层将持续演变，而持久性工作在于控制平面——它能让
这些模型变更是安全的。
为Sol、Terra、Luna以及任何非OpenAI候选模型建立一个小型注册表。
存储内容：
添加私有评估队列，确保新模型不能仅凭社交媒体印象就成为生产环境默认选项。
在智能体与关键工具之间放置授权代理。
暴露接口：
无论任务始于ChatGPT Work、Codex、自定义应用还是定时后台作业，均保持相同边界。
能够解释任务验证方式的团队，可以分阶段安全实现自动化。
无法定义验证标准的团队，无论基准测试分数多高，都不应让智能体持续运行数小时。
按以下维度追踪资金和人工时长：
这有助于协调模型路由、工具链效率和审查人员工作量。
当新一代旗舰模型发布时，团队也能给出有依据的回应。
发布材料中的多项声明仍由供应商自行报告。
跨供应商基准比较使用不同的：
应将这些声明视为内部测试的假设条件。
程序化工具调用和多智能体执行可减少上下文开销，但当追踪能力薄弱时，也可能使中间逻辑可见性降低。
在监管工作流中使用这些功能前，需验证：
ChatGPT Work的关联应用和计算机使用功能在扩展权限边界的同时提升实用性。可用性、管理控制和连接器权限可能因套餐和部署方式而异。
产品公告不能替代特定工作区的安全审查。
此外还存在人机协作问题。当智能体持续运行数小时，用户可能批准其未密切观察的工作。更好的摘要虽有帮助，但审批质量取决于能否在决策时刻展示预期效果、不确定性及失败检查。
产品设计必须保护人类注意力，而非简单请求点击操作。
因此，最强模型并非最终架构。
生产质量取决于以下要素的关系：
这种关系正是智能体控制平台所要明确表达的。
GPT-5.6是OpenAI于2026年7月发布的模型系列，分为Sol、Terra和Luna三个能力层级。Sol代表最高能力路径，Terra平衡能力与成本，Luna优先考虑速度和性价比。
ChatGPT Work是一个代理工作空间，用于跨文件、应用程序、浏览器操作、计算机使用等场景执行长时间运行的任务。
计划工作。与普通对话回合不同，工作任务围绕完成的成果或产物进行设计。
智能体控制平面是管理智能体运行的政策和操作层。它对任务进行分类，选择模型路由，发放限定范围凭证，应用工具限制，强制执行审批，记录跟踪信息，评估结果，控制预算，并管理恢复。
框架是组装上下文、暴露工具、存储状态、执行操作和管理重试的软件。控制平面则管理该框架的运行方式，包括权限、路由、预算、审批、评估和恢复。
Luna 适用于低风险的提取、分类和格式化任务。Terra 适用于常规的存储库工作、文档生成以及带有严格检查的中等程度分析。Sol 则更适用于模糊诊断、架构设计、安全审查和高价值研究。
不会。模型能力和操作权限应保持分离。从 Luna 或 Terra 升级到 Sol 应改变推理能力，而不是工具访问权限、写入权限、部署权限或审批要求。
公有基准测试可能包含有缺陷的任务、特定于框架的假设或信息泄露。它们有助于发现候选方案，但需要构建基于真实内部工作的私有评估来衡量成本、可靠性、审核负担以及实际环境中的安全性。
日志应包括目标、模型路由、推理过程、工具调用、来源、审批、错误、重试、令牌使用量、成本、耗时、产物、验证结果、升级原因和最终状态。
Sol 模型的早期技术预览。
GPT-5.6 为团队提供了更清晰的能力、成本、推理深度和多智能体执行选项。ChatGPT Work 将这些能力扩展到跨文件、应用、浏览器和定时工作流的持续性任务中。
生产环境的挑战不仅仅是选择最强的模型。团队还需要限定身份、精准的工具权限、审批关卡、独立的验收检查、完整追踪、多维预算、私有评估以及经过验证的恢复机制。
从一个可逆的工作流开始，记录人工基线，在影子模式下运行，并且每次只增加一个维度的权限。
生产级的智能体不仅仅是配备工具的强力模型。它是一个运行在可衡量、可逆且可问责的控制平面内的模型。
从一句话开始，几分钟内拿到完整网站。
