如果把过去三周几条官方更新连起来看，到 2026 年 6 月 9 日，一个变化已经比“模型又强了多少”更值得关注：AI 工作台正在从即时聊天界面转向持续执行系统。它不只要回答问题，而是要接住目标、保留上下文、管理中间状态、跨工具继续推进，并在任务没完成时自己知道下一步是什么。

这条线不是凭空出现的。2026 年 5 月 21 日，OpenAI 在 Codex release notes 里让 Goal mode 在 app、IDE extension 和 CLI 中普及，同时把 appshots、浏览器注释和 remote locked use 也放进长任务叙事。2026 年 6 月 2 日，OpenAI 又发布《Codex for every role, tool, and workflow》，把插件、注释和可分享的 Sites 正式推上主舞台。也是 2026 年 6 月 2 日，Microsoft 在 Build 2026 官方博客里发布 Scout，并把 agents、治理、运行和观察放进同一个系统视角。2026 年 6 月 1 日，AWS 则扩展 Amazon Bedrock AgentCore Gateway，让动态发现、streaming and session management、elicitation 与 OAuth on-behalf-of token exchange 直接进入 MCP 生产场景。把这些日期摆在一起看，目标和状态已经成了新一代工作台的中轴。

Goal mode 的真正意义，不是多了一个按钮，而是任务第一次被正式当成持续对象

很多人看到 Goal mode，第一反应可能是“又多了一个更长一点的代理模式”。但它真正关键的地方，不是代理能跑更久，而是产品开始明确承认：用户给 AI 的不只是一个提问，而是一个需要被持续追踪的目标。只要目标被显式建模，系统就必须知道成功条件、当前进展、剩余阻塞和失败后的回报方式。

这和普通聊天有根本差异。聊天界面的主单位是消息，而目标模式的主单位是任务。消息更适合局部协商，任务才适合跨文件、跨工具、跨时间推进。2026 年 5 月 21 日 OpenAI 把 Goal mode、appshots 和浏览器注释一起发布，本质上是在补齐同一层东西：让系统不仅能听懂你说的话，还能知道你盯着什么、准备做什么、接下来该验证什么。

OpenAI 在 6 月 2 日继续推进插件和 Sites，说明目标模式必须长在真实工作流里

如果 Goal mode 只是一个孤立能力，它最多能改善代理内部调度，但未必能真正改变交付。真正让方向清晰的是 2026 年 6 月 2 日 OpenAI 又把插件和 Sites 放进 Codex 主叙事。因为一旦代理开始围绕分析、设计、销售、研究和运营等岗位工作，它面对的就不再只是“生成一个回答”，而是“把结果送进团队当前使用的工具和交付物”。

插件解决的是连接面，Sites 解决的是结果承接面，Goal mode 解决的是推进面。三者一拼起来，产品形态就明显变了。用户不再只是问一句“帮我写”，而是给出一个目标，然后让系统在连接层拿到上下文，在执行层推进步骤，在结果层交付一个可继续迭代的产物。这已经越来越像工作台，而不是聊天框。

  • Goal mode 负责定义目标、成功条件和阶段推进。
  • 插件负责把系统接进当前团队真实使用的工具链。
  • Sites 负责承接结果，让产出不再停在对话窗口里。

Microsoft Scout 进一步说明，个人代理正在从“对话伙伴”变成“持续在线执行入口”

Microsoft 在 2026 年 6 月 2 日的 Build 2026 官方博客里给出的信号也很直接。Scout 被定义成新的 personal agent for work，而整篇叙事并没有把重点放在某个单独模型能力上，而是把 agents、控制、观察、信任和运行时放在同一条系统链路里。这个表述很重要，因为它说明持续在线的代理，不能只靠更大的模型参数成立。

一旦代理要承接个人工作，它就必须跨过几个门槛：一是知道任务还没结束，二是知道自己可以访问哪些工具，三是知道什么时候应该停下来等人确认，四是知道结果应该回写到哪里。Scout 的意义正在于把个人代理的入口从“我再问一轮”改成“这个工作是否还在持续推进”。这和 Goal mode 的方向是同一条线，只不过 Microsoft 把它说得更偏平台化、更偏运行时。

AWS 把状态真正推到连接层：没有会话和委托认证，目标模式只能停在界面层

很多人会把 Goal mode 理解成前端交互创新，但真正决定它能不能跑通的，其实是底层连接层是否支持状态。AWS 在 2026 年 6 月 1 日扩展 AgentCore Gateway 的价值，就在这里。动态发现意味着代理在运行时能找到当前可用资源；streaming and session management 让状态可以在多轮调用中稳定延续；elicitation 允许代理执行到一半再回来补要缺失信息；OAuth 2.0 on-behalf-of token exchange 则让身份与权限能沿着任务链路一起流动。

这几项能力拼起来，才让“目标模式”不只是 UI 里的设定，而是可以落到 MCP 生产场景里的持续执行能力。否则任务一跨系统，状态就会断，权限就要重猜，中间信息就会丢，代理很快又退回成一次次短对话。AWS 这轮更新说明，下一代工作台的核心竞争力之一，不只是会不会规划，而是状态能不能穿透工具和身份边界。

浏览器注释、appshots 和远程锁屏继续工作，补上的是执行现场

还有一层变化容易被忽略，那就是执行现场本身开始成为产品的一部分。OpenAI 在 2026 年 5 月 21 日同批推出的 appshots、in-app browser annotations 和 locked computer use，看起来像分散的小功能，实际上是在回答同一个问题：当代理处理长任务时，它怎么保持对现场的理解？

真实任务很少只存在于文本里。一个页面排版问题可能要看浏览器标注，一个运营流程可能要参考应用窗口，一个持续执行的自动化可能会跨过用户离开电脑的时间段。如果这些现场信息无法持续附着，目标模式就容易沦为“更长一点的文本计划”。而当现场、状态和目标被同时保留时，工作台才真正长出了执行层。

为什么这会先改变内容站、内部工具和小团队流程

这波变化离个人项目并不远，反而非常近。像一个内容站点每天更新文章，完整任务通常不是“写出正文”这么简单，而是核实最近几天的官方动态、选一个和既有主题连续的角度、生成配图、落静态页面、同步首页、更新文章列表、回写 SEO 和站点地图、部署服务器、验证结果，再把 Git 记录推上去。只要系统不能保留目标和状态，每一步都会重新解释一次。

一旦目标模式真正接入工作流，最先受益的恰恰是这种重复但跨系统的任务。因为它们最怕上下文断裂，也最需要中间状态被可靠继承。未来很多小团队真正需要的，不会是一个更会聊天的助手，而是一块知道目标、知道当前阶段、知道工具边界、知道结果要回写到哪里的工作台。

下一轮竞争，很可能是“谁先把目标模式做成执行系统”

把 2026 年 5 月 21 日 OpenAI 的 Goal mode 更新、2026 年 6 月 2 日的插件与 Sites、同日 Microsoft 的 Scout，以及 2026 年 6 月 1 日 AWS 的状态化 MCP 能力串起来，一个结论已经相当明确：目标模式开始接管长任务，而 AI 工作台正在从聊天走向持续执行系统。

接下来更值得建设的，不会只是更长的提示词，而是目标定义、状态继承、权限流动、现场附着、结果回写和失败回报这些结构能力。谁先把这些能力接成一个稳定回路，谁就更容易把最新 AI 动态转成每天能交付的真实产能。