Codex 这阵子的动作,明显在往”企业能用”那个方向使劲。
不是加个炫功能,是把账号、账单、审计这些公司真正在乎的东西一点点补齐。
一、GitLab 支持进了 beta
8 月 19 日,Codex cloud 里 GitLab 支持以 beta 形式上线,所有 ChatGPT 套餐都能用。
连一个 GitLab 项目,给它建个环境,从 issue 或 merge request 直接起任务,用 @codex 请它审 MR,或者要一次性的、自动的 MR 评审。
注意两个限制:GitLab 自托管或专用版需要 workspace 管理员先配连接;如果 GitLab 把一个折叠或超大的 diff 吞了,Codex 是没法完成评审的。集成跑在 Codex cloud,不是你本地。
二、服务账号和成本账单也来了
8 月 13 日两样东西值得公司里的负责人看:
服务账号:符合条件的 workspace 能建非人类的账号,给 CI runner 和定时任务发带作用域的 token,还能分角色、分组、共享账号管理。
线程级成本数据:按积分计费的企业 workspace,能在 Codex 里看每个对话的累计积分消耗。数字是估算、是规划参考,不是发票,但起码能知道钱花哪了。
线程级成本数据:按积分计费的企业 workspace,能在 Codex 里看每个对话的累计积分消耗。数字是估算、是规划参考,不是发票,但起码能知道钱花哪了。
再早一天(8 月 18 日),iOS 端还加了 Codex Remote、标准 MCP 表单和可编辑的 Messages 审批。MCP 这一块,Codex 已经吃进了 2026-07 那版协议,含分页发现和多轮请求。
三、圈圈的判断
把这几件事放一起看,Codex 在把”写代码的助手”改造成”团队里的一个工程岗位”。
它有账号(服务账号)、有账单(成本数据)、有对接(GitLab)、有审批(MCP forms)。公司要接手一个 agent,关心的无非就是这几样:谁能管、钱怎么算、出了事追得到谁。
对在用 GitLab 的团队,我的建议是先在测试项目上跑一遍 MR 评审,确认 diff 不被吞,再往主干推。别一上来就把生产仓库的审批权限交给它。
—— 圈圈
没有回复内容