过去一年，AI 编程工具的竞争重点大多是：哪个模型更强，哪个 agent 更会改代码，哪个工具更适合 vibe coding。

最近的变化不太一样。

OpenAI 在 Codex 里更新了 Appshots、Goal mode、远程锁屏使用和浏览器能力。GitHub 在做 Agent HQ。Multica 这类项目开始把 coding agents 放进任务看板、运行环境、技能复用和进度追踪里。Chrome DevTools MCP 让 agent 可以直接调试浏览器。.NET Skills 这类项目把语言生态知识打包给 agent 用。

这说明 AI 编程正在从“一个聊天框帮你写代码”，变成“一个可分配、可追踪、可复用、可验证的开发系统”。

Codex 这次更新，重点不是某一个按钮

OpenAI 在 2026 年 5 月 21 日的 release notes 里写到，Codex 获得了更多理解工作上下文、推进长任务的能力。

这次 Codex 更新里比较关键的能力

Appshots

macOS 版 Codex 可以用快捷键把当前应用窗口附加到 Codex 线程里，包括截图和可用文本。这个功能解决的是“怎么把当前工作现场交给 agent”。

Goal mode

Goal mode 已经在 Codex app、IDE extension 和 CLI 里进入可用状态。用户可以定义结果和成功标准，让 Codex 持续推进任务。

Remote locked use

符合条件的 Mac Computer Use 用户，可以在 Mac 锁屏后继续让 Codex 远程安全工作，但受现有区域限制影响。

浏览器能力提升

包括更精确的浏览器标注、更快的资源提取、只读 JavaScript 上下文、减少 Chrome extension 的标签页混乱，以及可靠性改进。

插件共享

Business 工作区可以通过 marketplace sources 分享插件包。插件包里可以包含 skills、app integrations、MCP servers 和 lifecycle hooks。

单独看，这些是功能更新。放在一起看，它们分别对应五件事：输入上下文、长任务推进、远程执行、浏览器验证、团队复用。

Codex 自己也在往“代理管理”走

Codex 文档里已经有 subagents 和 custom agents。官方描述是：Codex 可以生成专门的子代理并行工作，再把结果汇总到一个回复里。这类流程适合高度并行的复杂任务，比如代码库探索，或多步骤功能计划。

文档里还写到，用户可以定义不同配置和指令的 custom agents，让不同 agent 承担不同任务。比如一个 agent 只做代码路径探索，一个 agent 专门找正确性和安全风险，一个 agent 负责查文档。

重点不是“多开几个 agent”

真正的变化是：任务可以被拆成不同角色，有的只读代码，有的审查风险，有的查文档，有的执行修改。人的工作从“亲自改每一处代码”，变成“设计任务、分配角色、验收结果”。

这类用法对独立开发者也有意义。一个人做产品时，最缺的不是聊天框，而是并行检查能力。代码质量、安全、测试、文档、兼容性，如果每次都由一个 agent 串行完成，很容易漏，也很耗时间。

GitHub Agent HQ：平台层开始做控制台

GitHub 也在做类似方向。公开报道显示，GitHub 正在推出 Agent HQ，让开发者在 GitHub 内使用来自 OpenAI、Anthropic、Google 等公司的 coding agents，而不是只使用 GitHub 自家的 Copilot。

报道里提到，Agent HQ 会提供一个 mission control dashboard，用来控制、管理和追踪多个 AI coding agents。开发者可以让多个 agents 并行处理同一个任务，再选择自己更满意的结果。

GitHub 还在 VS Code 里加入 Plan Mode，让 Copilot 先生成任务计划，再交给 AI coding agent 执行。代码审查流程也在加入 CodeQL 等工具，先评估代码，再交给开发者看。

这里的信号很明确

平台不再只想卖一个“AI 补全工具”，而是想成为多个 agent 的入口、控制台和审查层。

Multica：把 coding agent 放进看板里

Multica 是一个开源 managed agents 平台。它的定位很直接：把 coding agents 变成真实队友。你可以像给同事分配 issue 一样，把任务分配给 agent。agent 会领取任务、写代码、报告阻塞、更新状态。

Multica 的 README 里写到，它支持 Claude Code、Codex、GitHub Copilot CLI、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI 等工具。它不是替代这些 agent，而是给这些 agent 套上一层协作和管理界面。

任务分配

像分配 issue 一样分配给 agent。

状态追踪

看 agent 领取、执行、完成或失败。

Squads

把 agent 和人组成小队，由 leader agent 分配任务。

Autopilots

用 cron、webhook 或手动触发周期性工作。

Reusable Skills

把解决方案沉淀成团队可复用技能。

统一 Runtime

本地 daemon 和云端 runtime 统一监控。

这类工具的价值不在于让单个 agent 更聪明，而是解决多个 agent 干活时的几个现实问题：谁在做什么、做到哪一步、遇到什么阻塞、结果能不能复用。

Chrome DevTools MCP：让 agent 不再只猜前端问题

前端开发里，AI 很容易写出“看起来对”的代码，但实际浏览器里可能有样式问题、性能问题、网络请求问题、console 报错。

Chrome DevTools MCP 的作用，就是让 coding agent 可以控制和检查实时 Chrome 浏览器。它作为 MCP server，让 Claude、Cursor、Copilot 等 agent 能拿到 Chrome DevTools 能力，用于自动化、调试和性能分析。

官方项目列出的能力包括：记录性能 trace 并提取性能洞察、分析网络请求、截图、检查 console message、用 Puppeteer 自动执行浏览器动作并等待结果。

安全提醒

这个工具会把浏览器实例里的内容暴露给 MCP client。项目文档提醒，避免把不想交给 agent 的敏感或个人信息放进浏览器里。

对独立开发者来说，这类工具最适合放在“验收”环节：让 agent 改完页面后，不只看代码，还要打开浏览器检查页面、跑交互、看 console、看 network。

.NET Skills：技能包开始变成生态资产

dotnet/skills 是 .NET 团队整理的一套 agent skills 和 custom agents。它不是一个通用聊天工具，而是把 .NET 相关知识、习惯、诊断方式打包给 coding agent 用。

仓库里包含多个插件：dotnet、dotnet-data、dotnet-diag、dotnet-msbuild、dotnet-nuget、dotnet-upgrade、dotnet-maui、dotnet-ai、dotnet-template-engine、dotnet-test、dotnet-aspnet、dotnet11。

这说明 coding agent 进入了一个新阶段：不再只拼模型本身，也开始拼“技能包”。同一个模型，如果加载了更准确的工程知识、诊断流程和生态规范，做事质量会更稳定。

这些工具放在一起，说明了什么

这几类工具表面不一样：Codex 是官方 agent，GitHub 是平台入口，Multica 是管理层，Chrome DevTools MCP 是浏览器调试层，.NET Skills 是知识层。

但它们都在解决同一个问题：单个 agent 会写代码还不够，真实开发需要任务分配、上下文输入、运行环境、技能复用、浏览器验证、代码审查和进度追踪。

过去的 AI 编程

人把需求丢进聊天框，AI 写一段代码，人自己判断能不能用。

现在正在出现的 AI 编程

人拆任务、分配角色、挂工具、看进度、查证据、验收结果。AI 不只是写代码，而是进入开发流程。

哪些人现在可以开始试

不是所有人都需要马上上多代理管理。下面几类人更适合试：

独立开发者

同时要做开发、测试、文档、上线、修 bug，可以用 agent 分担重复核查。

前端开发者

Chrome DevTools MCP 适合页面验证、console、network、performance。

小团队

需要知道 agent 在干什么、谁负责哪个任务、结果怎么复用。

.NET 团队

dotnet/skills 这类技能包能降低 agent 在生态知识上的试错。

不适合盲目上多代理的情况

多代理不是越多越好。下面这些情况，先别急着上复杂工具：

• 任务本身还没拆清楚，只是想让 agent 自己想办法。
• 项目没有测试和验收标准，agent 做完以后没人能判断对错。
• 浏览器里有敏感账号、内部后台、客户数据，不适合直接暴露给 MCP client。
• 只是偶尔让 AI 改一个小文件，用普通 Codex / Claude Code 就够了。
• 团队还没有统一 issue、PR、测试、review 流程，多代理只会放大混乱。

一个可以直接抄的小工作流

如果你是一个人做产品，可以先用一个很小的流程试，不要一开始就搭复杂系统。

这个流程不追求炫技。它只解决三个问题：让 agent 知道自己该干什么，让人知道 agent 干到哪了，让结果可以被检查和复用。

这波变化真正影响的是工作方式

如果只看模型能力，很容易以为 AI 编程工具的竞争还停留在“谁更会写代码”。

但最近这些更新显示，工具层已经开始补齐开发流程里的其他环节：任务管理、上下文输入、浏览器验证、团队插件、技能沉淀、agent 控制台。

对普通程序员来说，这意味着要学的不只是 prompt。更重要的是怎么拆任务、怎么定义验收、怎么让 agent 只做该做的事、怎么验证结果。

对独立开发者来说，这件事更实际：一个人做产品，最缺的不是又一个聊天窗口，而是一套能让 AI 持续参与开发、测试、排查、复盘的工作系统。

来源说明

本文参考 OpenAI ChatGPT Release Notes、OpenAI Codex Subagents 文档、Multica GitHub README、Chrome DevTools MCP、dotnet/skills、GitHub Agent HQ 相关公开报道。功能状态以官方页面和项目 README 为准。

如果这篇文章对你有一点帮助，欢迎点个赞，也点个在看。