信号
最近 OpenAI Codex 的几个更新放在一起看，释放了一个非常清晰的信号：
Agent 产品的核心，不再只是“能不能操作电脑”，而是能不能自动选择最稳、最快、最安全的行动模式。
OpenAI Devs 宣布 Codex 的 Computer Use、Chrome Extension、personalized memory、Chronicle 等能力在欧洲、英国、瑞士进一步开放；同时，社区也在讨论 Computer Use、Browser Use、Chrome Extension、Appshots 之间的区别。(OpenAI)(Chronicle)(OpenAI Devs)
表面上看，这是 Codex 多了几个功能入口。
但真正重要的不是这些功能名称，而是它背后的产品趋势：
用户不应该理解底层操作模式。用户只应该说目标，系统负责选择行动路径。
用户真正关心的不是：
“这是 Computer Use 吗？”
“这是 Chrome Extension 吗？”
“这是 Appshots 吗？”
用户真正关心的是：
这件事能不能完成？ 是不是足够快？ 会不会点错？ 能不能回滚？ 是否需要我确认？ 会不会泄露敏感信息？ 过程能不能被记录和审计？
所以，下一代 Agent UX 的基础设施，很可能不是一个更复杂的工具栏，而是一个 Action Mode Router。
也就是：
根据任务目标、应用环境、登录态、权限风险、可观测性和可回滚性，自动选择最合适的行动模式。
五种行动模式
可以把几种模式理解成五层。
1. API / MCP / Plugin：最优先的结构化路径
能走 API，就不要看屏幕。
能走 MCP 或插件，就不要模拟点击。
这类路径最快、最稳定、最容易审计，也最适合企业级场景。
比如读取 GitHub issue、更新 Linear ticket、查数据库、创建文档、调用内部系统接口，这些都应该优先走结构化路径。
2. In-app Browser：适合受控网页操作
如果任务发生在网页里，但不需要复杂登录态，或者主要是前端预览、页面检查、UI 修改、样式标注，in-app browser 就足够。
它比 Computer Use 更可控，也更容易留下操作轨迹。
3. Chrome Extension：适合复用真实登录态
Chrome Extension 的价值在于，它可以使用用户已经登录过的 Chrome 环境。
这适合处理 CRM、后台系统、运营平台、Google Docs、Sheets、Dashboard 等任务。
它不是万能操作电脑，而是更适合“网页应用里的真实工作流”。
4. Appshots：先看清现场，再行动
Appshots 的意义不是直接执行，而是把用户当前正在看的应用状态转成上下文。
过去用户要解释：
“我现在在这个页面，这里有一个按钮，左边这个表格有问题……”
现在可以变成：
Agent 先看到当前窗口状态，再判断下一步该怎么做。
这一步很关键。因为 Agent 最怕的不是不会操作，而是不知道用户当前处在什么现场。
5. Computer Use：最后手段
Computer Use 覆盖面最广，因为它可以看屏幕、点击、输入，像人一样操作桌面应用。
但也正因为如此，它通常更慢、更脆、更高风险。
所以 Computer Use 不应该成为默认路径，而应该是最后手段：
当 API 不存在、插件不覆盖、浏览器自动化不够、必须跨 App 或必须处理 GUI 时，才升级到 Computer Use。
产品判断
这条信号对 Agent 产品设计非常直接：
不要把“选择工具”的复杂度交给用户。
用户不应该在界面上选择：
API 模式、浏览器模式、Chrome 模式、截图模式、电脑操作模式。
真正好的产品应该让用户只输入目标：
“帮我检查这个页面的问题。”
“帮我把这个客户信息同步到 CRM。”
“帮我整理这个表格并发给团队。”
“帮我把这个功能跑通并提交 PR。”
然后系统内部自动判断：
有没有 API？ 有没有插件？ 是否需要登录态？ 是否涉及发送、删除、支付、发布？ 能不能 dry-run？ 是否需要用户确认？ 失败后能不能回滚？ 过程是否可审计？
这就是 Action Mode Router 的价值。
一个可执行的行动策略
未来 Agent runtime 可以采用这样的默认优先级：
API / MCP / Plugin
→ In-app Browser
→ Chrome Session
→ Appshots Context
→ Computer Use with Confirmation换句话说：
第一，默认选择最结构化、最可审计的路径。
第二，只有结构化路径不够用时，才进入浏览器或 Chrome session。
第三，跨 App 或上下文不清楚时，先用 Appshots 看清现场。
第四，只有在没有更好路径时，才升级到 Computer Use。
第五，凡是高风险动作，都必须确认、dry-run 或提供回滚方案。
对产品架构的启发
每一个 action 都不应该只是“执行一次”。
它应该带上治理字段：
- action 类型
- 风险等级
- 预期耗时
- 权限范围
- 是否需要登录态
- 是否可回滚
- 是否需要用户确认
- 可观测日志
- 失败恢复方案
- 下次是否可复用
这意味着：
运行时可以薄，但治理账本必须厚。
skill、action、credential、spending、subagent、memory，都应该有生命周期、权限边界、验收标准和回滚方案。
可落地 artifact
这条信号不应该只被收藏，而应该转成一个可执行 artifact：
Action Mode Router Skill
输入：
- 任务目标
- 目标应用
- 是否需要登录态
- 是否涉及支付、删除、发送、发布
- 是否有 API / MCP / Plugin
- 是否需要跨 App
- 是否需要读取当前屏幕状态
- 是否允许自动执行
- 是否需要人类确认
输出：
- 推荐行动模式
- 权限请求
- 执行计划
- 风险等级
- dry-run 方案
- 回滚方案
- 日志字段
- 下一次复用方式
可以进一步沉淀成一套 Action Policy DSL：
read_only_api
→ browser_read
→ chrome_session
→ appshots_context
→ computer_use_confirmed这套 DSL 的核心不是炫技，而是让 Agent 的每一次行动都有边界、有记录、有验收、有恢复。
风险与反信号
这条趋势也有风险：
如果过度路由，简单任务会变慢。
如果策略太复杂，用户会觉得 Agent “想太多”。
如果确认太频繁，自动化体验会被打断。
如果权限设计不清楚，Chrome Extension 和 Computer Use 都可能带来安全风险。
如果屏幕上下文被滥用，Chronicle / Appshots 类能力会引发隐私和 prompt injection 问题。
所以，关键不是“模式越多越好”，而是：
默认简单，风险升高时才变复杂。
下一步验证
可以用 30 个真实日常任务做一轮评测：
同一个任务分别用 API、Chrome Extension、in-app browser、Computer Use 执行，记录四个指标：
- 成功率
- 平均耗时
- 人类干预次数
- 错误与回滚成本
最后沉淀一张 Action Mode Decision Matrix。
这会比单纯讨论“Computer Use 强不强”更有价值。
一句话总结
真正的 Agent UX，不是让用户选择工具，而是让系统自动选择最稳、最快、最安全的行动模式。