夜雨聆风2026 年 5 月 21 日，OpenAI 给 Codex 做了一次很关键的更新。
如果只看功能列表，它像是一次开发工具升级：Appshots、Goal mode、浏览器标注、locked computer use、Analytics。
但如果把这些能力放在一起看，信号就不一样了。
Codex 正在从一个“代码助手”，变成一个可以理解上下文、设定目标、持续推进、远程操作、被企业观测和治理的 AI 开发员工。
这不是 Copilot 的增强版。
这是软件工程组织结构开始变化的前奏。
一、Appshots：AI 开始真正“看见”你的工作现场
过去使用 AI 编程工具，最大的成本不是写 prompt，而是解释上下文。
你要告诉它：我在哪个页面、看到什么错误、当前 UI 是什么状态、文档里哪一段重要、终端里输出了什么、设计稿哪里不对。
Appshots 解决的正是这个问题。
OpenAI 官方文档显示，Appshots 可以把 Mac 前台窗口作为附件加入 Codex 线程，包括可见窗口截图，以及应用能够提供的可用文本。某些场景下，它还可以读取可见区域之外的文本。这个变化很关键，因为它让 Codex 的输入不再只是“人类描述”，而是“真实工作现场”。
这意味着什么？
一个开发者打开 API 文档、错误页面、邮件、设计预览或配置面板，不再需要把内容复制出来再解释一遍。Codex 可以直接基于当前窗口理解问题，再回到代码库里行动。
在企业环境里，这一步的意义很大。因为企业软件开发的上下文从来不只在代码里，还散落在 Jira、Linear、GitHub、Slack、内部文档、监控系统、接口平台、设计稿和浏览器页面里。
Appshots 让 AI Agent 更接近真实员工的工作方式：先看现场，再决定怎么做。
但这也引出第一个治理问题：当 AI 可以看见屏幕，企业必须定义哪些内容可以被看见，哪些窗口不能被纳入上下文，哪些截图和文本需要审计。这已经不是简单的 prompt 管理，而是上下文权限管理。
二、/goal：从一次性回答，变成长周期执行
另一个更重要的变化是 Goal mode，也就是 /goal。
普通 prompt 是一次任务。
Goal mode 是一个持续目标。
OpenAI 文档里对它的描述很清楚：Goal mode 给 Codex 一个可持续推进的目标，适合多步骤任务；目标文本既是起始提示，也是完成标准。它可以在 Codex App、IDE extension 和 CLI 中使用，并支持暂停、恢复、编辑和清除目标。
这其实是 AI 开发工具的一次范式变化。
过去我们让 AI 做的是：“帮我写一个函数”“解释这段代码”“补一个测试”。
现在我们开始让 AI 做的是：“把这个模块迁移到 TypeScript，确保严格模式通过”“把首页 TTI 降到 1 秒以内”“修复这条 CI 链路，并补齐回归测试”。
前者是任务。
后者是目标。
目标意味着 Agent 需要持续判断：下一步做什么、是否偏离方向、是否达到验收标准、是否需要请求人工决策。
这也是为什么 Coding AgentOps 会变得重要。只要 AI 开始长周期执行，就必须管理任务生命周期：目标定义、进度记录、中间状态、暂停恢复、失败原因、人工接管、最终验收。
没有这些能力，Agent 很容易变成一个“跑很久但没人知道它在干什么”的黑盒。
三、Locked computer use：AI 开始使用真实桌面
更具冲击力的是 locked computer use。
OpenAI 的 Computer Use 文档显示，Codex 可以在用户授权的应用中查看和操作界面。Locked computer use 则允许在 Mac 锁屏后，Codex 仍然通过受限机制继续使用 Computer Use。官方也强调，这不是通用远程解锁能力，而是一个短时、限定在活跃可信 computer use turn 内的机制。
这说明 AI Agent 正在进入真实桌面环境。
它不只是调用 API，也不只是改文件。它可以打开应用、点击按钮、读取页面、操作窗口、处理浏览器里的状态。对于研发来说，这意味着它可以验证前端页面、调整 UI、复现 bug、检查错误状态，甚至在移动端远程推动本地机器上的工作。
但这里的风险同样明显。
如果一个 Agent 能操作浏览器，而浏览器里用户已经登录企业系统，那么它的点击、表单提交和页面访问就可能被系统视为用户本人的行为。企业必须把这类能力纳入审批、权限和审计体系，而不是把它当成“更聪明的自动化脚本”。
换句话说，Computer Use 的出现，让 AI 开发工具第一次拥有了真实环境副作用。
四、技术拐点：Coding Agent 的闭环成型了
把 Appshots、/goal、Computer Use、浏览器标注放在一起看，一个完整的 Coding Agent 闭环已经出现。
传统 AI 编程助手的中心是模型能力。
Coding Agent 的中心是工作流能力。
它必须知道自己在哪个 repo，当前目标是什么，能调用哪些工具，哪些命令需要审批，哪些文件能改，测试是否通过，PR 是否被 review，失败后如何回滚。
所以，企业真正要建设的不是“让大家都用上 Codex”，而是让 Codex 这类工具进入一个可管理的生产体系。
这个体系，我称为 Coding AgentOps。
五、什么是 Coding AgentOps？
Coding AgentOps 是面向 AI 开发 Agent 的运维、治理和效能体系。
它和 DevOps、MLOps 类似，但对象不同。
DevOps 管软件交付。
MLOps 管模型训练和部署。
Coding AgentOps 管 AI 开发员工如何在真实代码库和真实工具链中工作。
它至少包括六层能力：
这里最容易被低估的是观测层。
OpenAI 的 Codex Governance 文档已经提到，企业可以通过 Analytics Dashboard、Analytics API 和 Compliance API 跟踪 Codex 的使用情况，包括不同产品入口的活跃用户、credits 和 token 消耗、threads 和 turns、代码评审活动、PR 评论、优先级问题、用户反馈等。
这说明 OpenAI 自己也在把 Codex 从个人工具推向企业系统。
企业不可能只问“AI 写了多少代码”。更重要的问题是：它在哪些仓库里工作？失败率是多少？花了多少 token？哪些 PR 评论被人类采纳？哪些团队把它用在高风险路径？哪些任务需要更多审批？
没有这些指标，AI 开发员工无法规模化管理。
六、企业怎么落地：先从研发效能平台开始
Coding AgentOps 最适合落地的第一个场景，不是客服，不是销售，而是研发效能平台。
因为开发工作天然具备三个特点：任务可拆分、结果可验证、变更可审查。
第一个场景是代码评审。
Agent 可以先做只读分析：检查 PR 的潜在 bug、测试缺口、异常处理、性能风险、安全问题。风险控制方式很明确：Agent 只能评论，不能合并；P0/P1/P2 问题需要人类确认；所有评论进入审计和反馈统计。
第二个场景是 CI 修复。
当构建失败时，Agent 可以读取日志、定位失败测试、修改代码或依赖配置，然后重新运行测试。这里的边界是：只能在临时分支工作；不能修改发布配置；高风险命令需要审批；最终以 PR 形式交付。
第三个场景是补测试和技术债治理。
这类任务往往重要但不紧急，很适合 /goal。比如“为订单模块补齐边界测试，覆盖退款、取消、并发提交三类场景”。Agent 可以持续推进，人类只需要审查 diff、覆盖率和测试结果。
第四个场景是前端 UI 调整。
结合 in-app browser 和标注能力，产品或设计同学可以直接在页面上指出溢出、间距、颜色、加载态问题，Agent 根据标注修改代码并验证页面。这里的风险控制是：限定路由、限定组件、限定视觉状态，并要求截图回传。
第五个场景是事故复盘。
Agent 可以读取告警、日志、代码变更记录、PR 历史和工单，生成初步事故时间线和根因假设。但在企业环境中，它不应该直接操作生产系统。它适合做分析、建议和文档化，执行动作仍要走审批。
七、企业落地路线图：不要一上来就全自动
真正成熟的企业不会直接把 Agent 放进生产环境里“自由发挥”。
合理路线应该是五步：
第一阶段，只允许 Agent 读代码、读日志、做分析，不产生副作用。
第二阶段，允许它修改代码，但必须在独立分支和沙箱中完成，所有变更由人审查。
第三阶段，接入审批流。比如执行迁移脚本、修改 CI 配置、访问内部工具，都需要明确授权。
第四阶段，开放低风险自动化。比如补文档、生成测试、修 lint、处理简单 UI 问题。
第五阶段，建设统一 Coding AgentOps 平台，接入身份、权限、日志、指标、成本、质量和合规系统。
这条路线看起来慢，但它才是企业真实可落地的方式。AI Agent 越强，企业越不能只靠“员工自觉使用”。
八、真正的变化：开发团队开始管理 AI 员工
过去的软件工程团队，核心问题是如何管理人和代码。
现在多了一个新对象：AI 开发员工。
它不是人，但会产生类似人的工作结果。
它不是普通工具，因为它会规划、调用工具、修改代码、解释原因。
它不是完全自主系统，因为它仍然需要人类定义目标、提供边界、审查输出。
所以未来研发组织的分工会发生变化。
人类开发者会越来越多地负责目标、架构、约束、验收和关键决策。
AI Agent 会越来越多地负责检索、修改、验证、迁移、修复和例行工程任务。
工程管理者则需要从“管理人效”扩展到“管理人机协作效能”。
这也是为什么 Coding AgentOps 会成为企业 AI 落地的第一块成熟战场。
因为它离业务足够近，能直接提升研发效率；同时它又足够工程化，可以被测试、审查、回滚和度量。
Codex 的这次更新，表面上是 Appshots、/goal、locked computer use。
本质上，是 AI 开发工具开始获得“工作现场”“长期目标”和“真实操作能力”。
下一阶段，企业要回答的问题不是“要不要用 AI 写代码”。
而是：
当 AI 已经可以像开发员工一样持续工作时，我们准备好管理它了吗？
