Codex 从写代码走向工作台：Sites、插件和权限
6 月 6 日前后，围绕 Codex 的讨论不再只是“它会不会写代码”。更值得关注的是几条产品信号正在合流：
- Codex Sites：把工作结果变成可分享的交互式网站或应用；
- role-specific plugins：把 apps、skills、instructions 和 workflow 打包；
- Lockdown Mode：强化运行时安全边界；
- 第三方 MCP / Skill 插件：把 Codex、Claude Code 和其他 Agent 串到更多工具里。
这说明 Codex 的方向正在变化：它不只是代码生成器，而是在变成一个工作台。
Sites 的价值不是“又一个建站工具”
OpenAI 官方把 Codex Sites 放在 Business / Enterprise 预览语境里，这个细节很重要。它不是面向个人随手做一个页面的玩具，而是把 Agent 的工作结果从“文件和 diff”推进到“团队可以打开、分享、继续协作的交互成果”。
比如：
- 客户复盘页面；
- 内部数据 dashboard；
- 项目状态页；
- 销售或运营临时工具；
- 会议后的行动清单；
- 代码变更的可视化说明；
- 需求讨论后的交互原型。
这类输出过去通常要经过很多中间环节：先写文档，再贴图，再找人做页面，再部署，再同步链接。Sites 的潜在价值，是让 Agent 直接生成一个可访问的工作产品。
| 传统交付物 | Agent 工作台交付物 | 变化 |
|---|---|---|
| Markdown 报告 | 可交互状态页 | 从“读结论”变成“查细节” |
| 静态截图 | 可点击原型 | 从“看效果”变成“试流程” |
| 代码 diff | 变更说明站点 | 从“看文件”变成“看影响” |
| 数据表 | 临时 dashboard | 从“复制数据”变成“探索数据” |
| 会议纪要 | 任务追踪页 | 从“记录讨论”变成“推动执行” |
所以 Sites 的重点不是建站，而是把 Agent 的输出变成团队可以继续使用的对象。
插件和 Skill 是能力层
OpenAI 文档里对 plugin 的定位很清楚：它可以包含 Skills，也可以依赖 approved apps。换句话说，插件不是一个简单按钮，而是一组可复用工作流。
这和 Claude Code 的 Skill 体系很像。好的 Skill 不是写满提示词，而是写清楚何时触发、读什么、跑什么脚本、如何验证、哪些动作必须请求确认。
| 能力 | 适合放在哪里 | 原因 |
|---|---|---|
| 团队代码规范 | Skill | 规则稳定，可复用 |
| PR 处理流程 | Plugin + GitHub app | 需要工具权限和统一分发 |
| UI 验收步骤 | Skill + Playwright MCP | 既有固定清单，又要操作浏览器 |
| 数据查询边界 | Skill + 数据库 MCP | 需要限定 schema、字段和写权限 |
| CAD/EDA 工作流 | Skill + 软件 API / MCP | 高风险动作要先快照、再审批 |
插件化的意义，是让团队不必每个人都复制同一套提示词、脚本和说明。一个团队可以把“如何评审 PR”“如何做 UI 验收”“如何处理客户复盘”“如何生成周报”打包成可安装能力。
权限会成为分水岭
Agent 一旦能连浏览器、GitHub、数据库、Figma、Slack、Salesforce，真正危险的不是它不会用，而是它太会用。
所以 Lockdown Mode、权限审批、workspace app controls 这些能力会变成基础设施。以后评价一个 Agent 平台，不能只看模型多强，还要看：
- 有没有最小权限；
- 能不能审计工具调用；
- 能不能隔离工作目录；
- 能不能阻止任意网络和 shell 扩散；
- 能不能让管理员关闭某个 app-backed capability；
- 能不能区分“读取、建议、写入、发布”四类动作。
| 权限层级 | 允许动作 | 适合默认开启吗 |
|---|---|---|
| 读取 | 读文件、读文档、读 issue、读日志摘要 | 可以，但要限制范围 |
| 建议 | 生成 diff、生成 SQL、生成回复草案 | 可以，但不直接执行 |
| 写入 | 修改代码、更新 issue、写数据库 | 需要明确触发和审计 |
| 发布 | 部署、发邮件、提交审批、对外分享 | 默认应人工确认 |
Agent 平台如果想进企业核心工作流，权限模型必须比“允许/不允许”更细。真正需要的是“允许它读什么、能建议什么、何时能写、谁批准发布”。
从代码助手到工作台的三层结构
我会把 Codex 这条产品线理解成三层：
| 层级 | 作用 | 典型能力 | 衡量标准 |
|---|---|---|---|
| 生成层 | 产出代码、页面、报告、脚本 | 代码生成、重构、测试、文档 | 输出是否正确、可维护 |
| 工具层 | 连接真实工作系统 | MCP、apps、浏览器、GitHub、Figma、数据库 | 能否读取真实状态、减少人工搬运 |
| 治理层 | 控制权限、审计和分享 | Lockdown Mode、workspace controls、审批、日志 | 是否能安全进入团队流程 |
过去的编码助手主要停在生成层。接下来真正的竞争，会发生在工具层和治理层：谁能安全地接入更多系统，谁就能完成更完整的工作流。
不同角色会怎么用
| 角色 | 过去怎么用 AI | 工作台形态下怎么用 |
|---|---|---|
| 工程师 | 让 AI 写代码、补测试 | 让 Agent 拉 issue、改代码、跑验证、生成变更说明 |
| 产品经理 | 让 AI 写 PRD | 让 Agent 生成交互原型、状态页、验收清单 |
| 运营 | 让 AI 写文案 | 让 Agent 读取数据、生成 campaign 页面、追踪结果 |
| 销售 / 客成 | 让 AI 总结客户信息 | 让 Agent 生成客户复盘站点和后续任务 |
| 管理者 | 让 AI 总结周报 | 让 Agent 聚合项目、风险、成本和阻塞项 |
这也是 Sites 的意义：它让非工程角色也能拿到一个可以操作、可以分享、可以继续迭代的结果，而不是只拿到一段文本。
团队采用时的检查清单
- 插件是否写清楚触发条件和退出条件？
- Skill 是否包含验证步骤，而不只是提示词？
- app 权限是否按工作区和角色分层？
- 外部写入动作是否需要明确确认？
- Agent 的文件修改、工具调用和部署动作是否可审计？
- 生成的 Sites 是否有分享范围和过期策略？
- 失败后是否能回滚或重新生成？
我的判断
6 月上旬这波讨论的核心，不是 Codex 又多了几个功能，而是 Agent 产品开始形成三个层次：生成层、工具层、治理层。
单点代码生成能力会继续重要，但它不再是全部。真正的工作 Agent 必须能连接真实系统、生成可交互成果，并在权限、审批和审计上让团队放心。谁能把这三层合起来，谁就更接近下一代工作台。
来源
- OpenAI：Codex for every role, tool, and workflow
https://openai.com/index/codex-for-every-role-tool-workflow/ - OpenAI Help Center：Plugins in Codex
https://help.openai.com/en/articles/20001256-plugins-in-codex/ - OpenAI Release Notes
https://openai.com/products/release-notes/