0
| 本文作者： 郑佳美 | 2026-07-14 12:13 |
作者丨郑佳美
编辑丨马晓宁
北京时间凌晨一点，GPT 5.6 亮相 Open AI 发布会。
这场发布会没有只围绕一个模型展开，而是同时推出了 ChatGPT Work、全新的 ChatGPT 桌面 App、Hosted Sites，以及 GPT 5.6 系列模型 Soul、Terra、Luna。
单独看，这些像是几个不同功能；放在一起看，它们其实在补同一件事：让 ChatGPT 从一个生成回答的工具，逐步变成能接任务、读上下文、调工具、操作环境并交付结果的执行系统。
传统聊天产品主要处理“输入”和“输出”。用户问，模型答，任务大多停在聊天框里。执行系统要复杂得多，它要处理任务拆解、上下文管理、工具调用、状态跟踪、权限控制和结果校验。
发布会里的财务分析、Excel 更新、PPT 生成、桌面应用操作、网页托管和多 Agent 协作，都可以放进这条技术路线里理解。
这条路线可以先从产品链路看起。
01
ChatGPT Work 承担的是任务入口。
用户给它的请求，不再只是一段明确的文本，而是一个带有目标的工作任务。比如从 Slack 和员工反馈里找到内部典型使用案例，再结合行程安排访谈；或者读取财务数据，做 variance analysis，更新 forecast，生成汇报材料和可分享页面。
这种任务的难点在于编排。系统要判断需要哪些数据源，先读什么，后处理什么，哪些步骤可以自动执行，哪些地方需要用户确认。雷峰网
普通问答只需要处理当前输入，Agent 工作流则必须维护任务状态：已经用了哪些材料，得出了哪些中间结论，还有哪些假设没有确认。
任务入口解决之后，下一步自然是环境接入。因为真实工作很少只存在于一个聊天框里，更多时候分散在本地文件、浏览器标签页、表格、笔记、邮件和协作工具里。
这就是桌面 App 的意义。网页端主要依赖上传文件和云端连接器，桌面端可以接触本地文件、浏览器标签页和其他应用。
发布会里展示的 Apple Notes 整理、本地文件夹读取、Chrome 标签页分析和表格可视化，本质上是在让 ChatGPT 进入用户真实工作环境。
但接入环境之后，问题不会自动变简单，反而会多出一层上下文工程。
模型不可能把用户电脑里的所有文件、浏览器页面和历史记录都塞进上下文窗口。它要先判断哪些内容和任务相关，再把 PDF、Excel、网页、PPT、笔记等不同格式转成可处理的表示。这背后涉及文件索引、语义检索、上下文压缩、引用追踪和冲突处理。
比如同一个项目里，PDF、PPT、Slack 消息和 Excel 表格可能同时存在，信息还可能互相矛盾。Agent 不能只是把材料拼在一起，它要判断哪些来源更新、哪些来源可信、哪些内容只是背景材料。上下文越多，如果筛选和引用做不好，错误来源也会越多。
接入和理解环境之后，结果还要能交付。Hosted Sites 补的是这一端。
过去大模型输出多是文本、代码片段或静态文件，用户还要把结果搬到其他工具里继续处理。Hosted Sites 把结果直接变成网页、看板、内部工具或交互式原型，更适合临时 dashboard、项目汇报、产品原型这类轻量场景。
不过，交付层要稳定，不能只靠模型自由生成。Agent 调用工具时，需要结构化工具协议：输入字段是什么，返回结果怎么表示，失败状态怎么处理，哪些操作只读，哪些操作会产生副作用。
比如“更新 forecast”这种任务，如果只是让模型理解 Excel 后直接修改，风险会很高。更稳的方式是把动作拆成读取单元格、检查公式、生成 diff、等待确认、写回文件。
这样看，执行链路可以拆成三段：ChatGPT Work 接任务，桌面 App 接环境，Hosted Sites 交付结果。链路搭起来之后，问题就转向下一层：这么多步骤不可能都靠同一个模型硬跑，背后必须有模型调度。
02
GPT 5.6 这次拆成 Soul、Terra、Luna 三个层级。Soul 面向复杂 Agent 工作流，Terra 面向日常任务，Luna 面向高频低成本任务。
这个分层的重点在于调度。Agent 场景下，成本和延迟会被放大。一次复杂任务可能包含长文档读取、上下文压缩、多轮工具调用、代码生成、结果校验和多次修改。
如果每一步都调用最强模型，费用和响应时间都会上升；如果全程使用低成本模型，规划、推理和关键操作又可能不稳定。
所以更合理的方式是分层路由。摘要、分类、格式转换、批处理可以交给低成本模型；复杂规划、长上下文推理、代码生成、财务分析和高风险操作交给更强模型；中间步骤根据任务状态动态切换。用户看到的是一个 ChatGPT，系统内部实际要完成模型选择、上下文分配和工具调度。
当单个模型不足以覆盖复杂任务时，多 Agent 就会进入这套调度系统。
Ultra Mode 可以理解为把复杂任务拆给多个 Agent 并行处理。一个 Agent 读取资料，一个 Agent 处理表格，一个 Agent 生成页面，一个 Agent 检查一致性，最后再整合结果。这个方向能提高速度，也能在一定程度上做交叉检查。
真正难的是 orchestrator。它要决定任务怎么拆，每个 Agent 拿到哪些上下文，冲突结果如何处理，什么时候停止，怎样避免重复劳动，以及如何控制成本。多 Agent 系统如果没有稳定的调度层，只会让错误链路更长，排查也更困难。
模型调度还带来另一个问题：怎么评估它到底有没有变好。
这类系统不能只看传统问答 benchmark。发布会里提到 Terminal Bench、BrowseComp 和 Agent’s Last Exam，分别更接近代码执行、复杂信息检索和长周期专业任务。它们比单轮问答更贴近 Agent 场景，因为模型需要持续规划、查找信息、执行操作，并在中途修正。
但真实企业环境很难被标准测试集完整覆盖。真实任务里经常有权限限制、脏数据、历史包袱和组织内部口径。对 GPT 5.6 这类系统来说，更关键的指标应该是失败率、人工接管率、平均完成时间、工具调用成功率、结果可复核程度，以及单位任务成本。
模型调度解决的是“用什么模型、用多少成本、用什么方式完成任务”。当系统开始真的执行任务，下一个问题就变得更重要：用户能不能放心让它做。
03
Agent 系统越靠近真实工作环境，安全问题越具体。雷峰网(公众号：雷峰网)
过去模型安全更多关注输出内容，例如是否生成错误信息、敏感信息或危险内容。进入 Agent 阶段后，风险会落到动作上：读取了哪些文件，修改了哪些表格，调用了哪些工具，是否发送了消息，是否提交了代码，是否更新了业务系统。
发布会提到 GPT 5.6 在 cyber 能力上有明显提升，可以发现漏洞，也能生成补丁。这个能力用于防御有价值，但放进通用 Agent 产品里，也要求更严格的权限设计。一个能读文件、写代码、操作浏览器、调用企业系统的模型，必须被限制在清晰边界内。
可信 Agent 至少需要几层机制。
第一是最小权限。任务需要访问什么，就开放什么，避免因为一个简单任务暴露过多文件、连接器或应用。
第二是操作分级。读取资料、生成草稿、修改文件、发送消息、提交代码、更新财务模型，这些动作的风险级别不同，确认逻辑也应该不同。
第三是过程审计。系统需要记录模型读了什么、改了什么、依据是什么、哪些结论来自原始数据，哪些内容属于模型推断。财务、法务、安全和医疗这类场景尤其依赖审计链路。
第四是事务化执行。只要 Agent 能修改真实环境，就应该先生成计划和变更 diff，让用户或验证器检查，再一次性提交，而不是边想边改。修改 Excel、移动文件、发送消息、提交代码，都应该有 dry run、diff、确认和 rollback。
这和数据库事务的思路类似。关键不是保证每一步都不出错，而是出错后不能留下不可控的中间状态。Agent 如果没有事务机制，就很难处理高价值任务，因为用户无法判断它到底改了什么，也无法安全撤销。
在企业场景里，还需要运行观测系统。长任务执行过程中，系统应该记录每个子任务的输入、输出、工具调用、模型版本、耗时、失败原因和人工接管点。否则一旦结果出错，很难判断问题出在模型推理、上下文检索、工具接口，还是权限配置。
这类 observability 会成为 Agent 平台的基础能力。传统软件看日志、链路追踪和监控指标；Agent 系统也需要类似的执行轨迹。尤其在多 Agent 并行时，如果没有清楚的 trace，最后结果越复杂，排查成本越高。
可信边界也是财务 Demo 比 3D 页面更值得关注的原因。生成页面主要考验代码和交互能力，更新财务模型则涉及数据一致性、公式正确性、假设透明度和责任归属。
模型改了哪个单元格，PPT 里的数字是否与源表一致，forecast 的变化是否有明确依据，这些问题决定它能不能进入企业核心工作流。
整体看，GPT 5.6 发布会给出的技术路线已经比较清晰：先用 ChatGPT Work 接任务，再用桌面 App 接入真实环境，用 Hosted Sites 完成交付；底层通过 Soul、Terra、Luna 和 Ultra Mode 做模型调度；最后用权限、审计、事务和观测机制控制风险。
这几层是连在一起的。执行链路决定 ChatGPT 能不能把任务跑起来，模型调度决定它能不能以合理成本跑下去，可信边界决定用户敢不敢把关键任务交给它。
GPT 5.6 的价值，最终不会由发布会里的页面效果决定，而会由真实工作中的稳定性决定。
上车，带你看遍全球 AI 顶会精华
可独家畅览：
专家演讲PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
或点击「阅读原文」关注专区。
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
