AI 编程工具进入工作台阶段：Codex 与 Copilot 都在争夺 Agent 的日常入口

过去一年，AI 编程工具的主战场一直围绕模型能力：谁更会写代码，谁更懂仓库，谁能一次完成更长的任务。

但 2026 年 6 月 2 日，OpenAI 和 GitHub 几乎同时给出了另一个信号：下一阶段的竞争，重点不只是模型有多强，而是谁能把 Agent 放进日常工作流里，并让人类稳定地管理它的产出。

OpenAI 发布了 Codex 的新能力，强调 role-specific plugins、Sites 和 annotations；GitHub 则扩展 Copilot App 技术预览，并更新 Copilot CLI，加入 canvas、云端会话、云端自动化、定时提示、语音输入和 rubber duck 等能力。

这些功能看起来分散，实际指向同一个方向：AI 编程工具正在从“对话式助手”变成“可编排工作台”。

一、Codex 不再只围绕开发者

OpenAI 这次对 Codex 的定位很明确：Codex 起步于软件开发，但正在进入更多知识工作场景。

根据 OpenAI 6 月 2 日的官方发布，Codex 当前每周用户已超过 500 万；非开发者用户约占整体用户的 20%，并且增长速度超过开发者用户的 3 倍。OpenAI 同时推出了面向不同角色的插件、可分享的 Sites 预览，以及可以直接指向具体内容修改的 annotations。

这几个变化很关键。

插件解决的是“上下文从哪里来”的问题。分析师、市场团队、销售团队、产品设计团队并不总是从代码仓库开始工作，他们的上下文可能在 Salesforce、HubSpot、Slack、Google Docs、Coda、Figma、Tableau 或 Snowflake 里。Codex 如果要成为真正的工作入口，就必须理解这些工具里的业务语境。

Sites 解决的是“产出放在哪里”的问题。很多工作并不适合只落在一段聊天记录、一个 Markdown 文件或一张表格里。OpenAI 举的例子包括客户复盘页、财务模型场景规划器、产品发布资料中心。这类产物更像一个可以持续更新的轻量应用，而不是一次性文件。

Annotations 解决的是“如何修改”的问题。第一版内容生成出来之后，人类真正需要的是精确反馈：改这个导航栏字体、核对这条论断来源、把这张图表标签改清楚。注释式修改把反馈从“重新写一遍”变成“在具体对象上修补”。

这说明 Codex 的重点正在从“能不能生成代码”转向“能不能把工作对象接住，并持续迭代”。

二、GitHub Copilot App 把 Agent 工作变成可见对象

GitHub 在同一天扩展了 Copilot App 技术预览：现已面向已有 Copilot Pro、Pro+、Business 和 Enterprise 客户开放。

更值得关注的是新加入的 canvases。GitHub 把 canvas 描述为人和 Agent 共用的工作表面：Agent 可以更新 canvas，人类也可以在同一个表面上编辑、重排、批准或调整方向。

这不是单纯的 UI 改版，而是 Agent 产品形态的一次转向。

过去我们和 AI 编程工具协作，经常要在聊天记录里追踪它做了什么：它改了哪个文件，当前计划到哪一步，哪些测试失败，哪些 diff 值得看。任务越长，聊天记录越像噪声。

Canvas 的意义在于把 Agent 的中间状态外显。计划、PR、浏览器会话、终端、迁移清单、事故处理、表格、仪表盘，都可以成为一个可检查的工作对象。Agent 不再只是“在后台说它完成了”，而是把进度体现在对象本身的变化上。

这对工程团队很重要。因为真正阻碍 Agent 进入生产工作流的，往往不是它不会写代码，而是人类很难判断它是否真的做对了。

当进度、证据和可操作状态从聊天记录里搬到结构化界面上，Agent 才更容易被审查、复盘和接管。

三、CLI 也开始支持“定时与复核”

GitHub Copilot CLI 的更新同样值得放在一起看。

6 月 2 日的 GitHub Changelog 显示，Copilot CLI 新增了实验性终端界面、rubber duck、`/every` 与 `/after` 定时提示、语音输入等能力。

实验性终端界面加入了 tabs，开发者可以在 CLI 内查看 session、issues、pull requests 和 gists。语音输入让开发者可以用本地语音识别输入提示词。Rubber duck 则像一个内置复核 Agent，会检查当前计划、设计、实现或测试中的盲点，并把反馈交回主 Agent。

其中最值得注意的是 `/every` 和 `/after`。

这两个命令让 CLI 不只是一次性对话工具，而是可以在当前会话里安排任务：例如每 30 分钟运行一次前端测试，或者 2 小时后生成近期变更文档。它把 Agent 从“我问你答”推进到“按时间持续执行”。

这和 GitHub Copilot App 的云端自动化、OpenAI Codex 的可重复工作流，本质上是同一条线：Agent 需要从临时助手变成可安排、可追踪、可复核的工作单元。

四、为什么这是 AI 编程工具的关键转折

AI 编程工具最初的核心卖点是补全和生成代码。后来它们变成聊天助手，可以解释仓库、修 bug、写测试、处理 PR 评论。

现在，产品形态又走到下一步：它们开始争夺“工作台”。

工作台和聊天窗口的区别在于三件事。

第一，工作台有持久对象。任务、计划、页面、PR、浏览器状态、终端结果、自动化日程，都不应该只藏在聊天历史里。

第二，工作台有权限和边界。Agent 可以读哪些系统、改哪些文件、触发哪些流程、花多少预算，都需要被产品化管理。

第三，工作台有复核机制。人类不是只看最终答案，而是要检查中间状态、证据链、diff、测试和运行结果。

OpenAI 的 plugins、Sites、annotations，GitHub 的 canvases、cloud sessions、cloud automations、CLI schedules，都是在补这三件事。

这也意味着，未来评价 AI 编程工具不能只问“代码写得怎么样”。还要问：

• 它能不能接入真实工作上下文？
• 它能不能把产出变成可维护对象？
• 它能不能让人类低成本复核？
• 它能不能支持团队级权限、成本和审计？
• 它能不能把一次性任务沉淀成可复用流程？

谁先把这些问题解决好，谁就更可能成为团队日常工作入口。

五、对开发者和团队的直接影响

对个人开发者来说，今天可以开始调整使用方式：不要只把 AI 当成“问答窗口”，而要把它当成一个可以持续推进任务的协作者。

比如，写代码时可以让 Agent 先给计划，再让另一个复核角色找盲点；长任务可以拆成多个会话；周期性检查可以交给定时提示；前端改动要让 Agent 在浏览器里验证，而不是只看代码。

对团队来说，更重要的是治理。

当 Agent 可以连接更多工具、运行更多自动化、生成更多可分享页面时，它的价值会变大，风险也会变大。团队需要提前定义哪些任务适合 Agent 自动推进，哪些任务必须人工批准，哪些系统只允许只读访问，哪些产出必须留下来源和复核记录。

这不是保守，而是规模化使用 AI 编程工具的前提。

结语

6 月 2 日这组更新给出了一个清晰判断：AI 编程工具正在从“会写代码的聊天机器人”，演进为“围绕 Agent 协作设计的工作台”。

OpenAI Codex 试图把插件、Sites 和注释变成跨角色工作入口；GitHub Copilot 则把 App、CLI、canvas、云端会话和自动化串成更贴近工程团队的 Agent 工作环境。

下一阶段的竞争不会只发生在模型榜单上，而会发生在真实工作流里。

谁能让 Agent 的上下文更完整、产出更可见、过程更可控、复核更省力，谁就更接近成为团队默认的 AI 工作入口。

参考资料

• OpenAI, "Codex for every role, tool, and workflow", 2026-06-02
• GitHub Changelog, "Expanded technical preview availability for the GitHub Copilot app", 2026-06-02
• GitHub Changelog, "Copilot CLI: Improved UI, rubber duck, prompt scheduling, and voice input", 2026-06-02