Coding agent 正在离开聊天框

把 2026 年 2 月 2 日的 Codex app、2026 年 5 月 14 日的 Codex mobile preview，以及 Google I/O 2026 在 2026 年 5 月 19 日发布的 Antigravity 2.0 放在一起看，重点不只是模型更强，或者一次性能写更多代码。

这里出现了一个共同变化：coding agent 开始从“一个会写代码的对话框”，变成“能进入真实工作现场的执行系统”。

真实工作现场不在一个聊天窗口里。浏览器里有资料，终端里有测试，文件系统里有状态，文档里有决策，diff 里有风险，人的判断往往发生在审批、中断和复盘那一刻。

agent 进入这些地方以后，会更有用，也会更危险。

聊天框为什么不够了

只在聊天框里工作的 agent，最大的问题不是不聪明，而是离现场太远。

一个真实的软件任务，通常不是“写一段代码”这么简单。它会跨过这些环节：

• 读旧代码和项目约定。
• 查文档或产品资料。
• 修改文件。
• 跑测试、看日志、复现问题。
• 对比 diff。
• 根据结果继续调整。

如果 agent 只能在聊天框里给建议，它可以说得很完整，但很难对结果负责。因为它没有真正看到代码有没有编译，测试有没有过，截图有没有正常，文件有没有改到正确位置。

从这些官方动作看，agent 产品正在朝工作区靠近。

Codex 的信号：手机不是重点，接续工作才是重点

OpenAI 在 2026 年 5 月 14 日发布的 Codex mobile preview，表面看是“手机上也能用 Codex”。

它改变的不是写代码这一个动作，而是人和 agent 协作的位置。

官方说明里，Codex 可以在 ChatGPT mobile app 里接续正在运行的本地或远程环境。人可以从手机上查看 active threads、approvals、plugins、project context，也可以看到 screenshots、terminal output、diffs、test results 和 approvals。文件、凭据、权限和本地配置仍然留在 Codex 实际运行的机器上。

它更像是把几个关键判断点从电脑前搬出来：看线程、批命令、看 diff、确认测试结果。人不一定一直坐在机器前，但还能在关键节点把方向按住。

这里有一个很实际的变化：agent 可以跑更长的任务，但人不必一直坐在同一台机器前盯着它。

Codex app 的信号：agent 需要一个指挥台

OpenAI 在 2026 年 2 月 2 日介绍 Codex app 时，把它描述成面向多个 agent 的 command center。这个 app 支持多个线程、项目、worktree、diff review，也支持 skills 和 automations。

这说明 coding agent 的使用方式正在从“和一个 agent 对话”，变成“管理多个 agent 执行不同任务”。

一旦同时跑多个 agent，问题就变了：

• 哪个 agent 在动哪个项目？
• 它改了哪些文件？
• 它有没有跑测试？
• 它的 diff 能不能被审查？
• 它出错时会不会污染当前工作区？

这些问题不靠模型聪明就能解决。它们需要 workspace 边界、产物记录、审批点和可回放历史。

Antigravity 的信号：agent manager 从 IDE 里独立出来

Google 在 2026 年 5 月 19 日的 I/O developer highlights 里介绍了 Antigravity 2.0 desktop application；Antigravity 官方文档也把它定义成独立桌面应用，用来 launch、monitor 和 orchestrate agents。它不是只嵌在 IDE 里的一个侧边栏。

文档列出的能力也很直接：执行系统命令、读写文件、Web search、通过 skills 和 MCP 连接外部工具、管理 subagents、操作 Chrome、生成 artifacts 和 implementation plans。

这个方向和 Codex 很接近：agent 不再只是在编辑器里补全代码，而是开始覆盖命令行、浏览器、文件和外部工具。

这就是桌面执行环境的价值。它离真实工作更近。

但它也把风险带进来了。

agent 越能干，越需要被限制

一个只能写建议的 agent，错了最多浪费时间。

一个能执行命令、改文件、访问浏览器、调用外部工具的 agent，错了就可能改错目录、读错上下文、污染环境，或者把没有验证过的结果包装成完成。

这里有几个很容易在真实项目里发生的问题：

• 权限太大：agent 能动不该动的文件。
• 上下文错位：它以为自己在修 A，实际改到了 B。
• 命令太松：测试、安装、脚本执行改变了本地环境。
• 审查太弱：只给总结，不给可检查的 diff、截图、日志和 artifact。
• 中断困难：方向错了以后，人很难在损失变大前停住它。

所以评价 coding agent 时，不应该先问它能不能全自动。

先看五件事：

1. 工作区边界是否清楚。
2. 危险动作是否有审批点。
3. 产物是否能被检查，而不是只给一句“完成了”。
4. 人能不能随时中断和改方向。
5. 执行过程是否能回放，失败后能不能定位问题。

这些检查点不适合做发布会标题，但真用起来少不了。它们决定 agent 能不能长期进入真实工作流。

对自建 agent 系统的启发

这个判断也能放到自建 agent 系统里。

飞书、Discord、手机 App 都只是入口。

系统到底稳不稳，还是看背后几件事：它能读写哪里、技能怎么加载、产物放在哪里、什么时候必须停下来等人确认。

一个可用的 agent runtime，至少要把这些边界说清楚：

• persona 放在哪里。
• workspace 能读写哪里。
• skill 怎样被发现和加载。
• memory 什么时候能用，什么时候不能污染当前任务。
• 输出产物放在哪里。
• 哪些动作可以自动做，哪些动作必须停下来。

自媒体系统也是同一个问题。

这个工作流可以设计为：让 AI 读信息源、挑选题、写 X thread、配图、改公众号和小红书版本，再让内部 reviewer/subagent 审查和修正。中间不需要每一步都问人。

但外部发布还是要有边界。因为一条内容发出去以后，代表的是账号，不是一次临时实验。

更稳的方式是：系统自动完成中间工作，最终交付完整内容包、来源、审查记录和发布建议。人只在发布授权和周期性复盘里做判断。

结尾

“完全不用管的 agent”听起来很诱人，但真实工作里很难成立。

更现实的方向是：agent 可以进入更真实的工作现场，但每一步都留下可检查的痕迹。

更可靠的形态，是能留下记录的 agent：它可以改文件、跑测试、打开浏览器，但每一步要能看到改了什么、为什么改、哪里失败、怎么退回去。

桌面环境有价值，是因为这些检查点终于能放在同一个地方。

发布备注

• 标题备选：
  • Coding agent 正在离开聊天框
  • 桌面执行环境，会是 Agent 产品的下一站吗？
  • AI Coding 真正消耗人的地方，是 review
• 摘要：Coding agent 正在从聊天框走向真实桌面工作区。它会更有用，也更需要权限边界、审查表面和可恢复的执行记录。
• 外链处理：微信公众号正文不建议硬插外链。发布时可在文末放“参考资料”文字清单，或转为编辑备注。
• 事实边界：本文只使用官方页面可确认的产品能力，不写成亲测 Antigravity。