当前位置: 首页 > news >正文

ChatGPT、Codex趋势:Codex为什么正在走出程序员圈?Agent正在进入法务、销售和招聘

很长一段时间里,Codex几乎天然等于:

AI编程。

开发者用它:

写代码;

修Bug;

补测试;

做Review;

处理Repository。

所以大家很容易形成一个固定认知:

Codex主要就是程序员工具。

但这个认知正在快速过时。

OpenAI在2026年8月12日公布的最新企业数据里,一个非常反直觉的变化是:

自今年2月以来,企业Codex周活用户在法务增长108倍、销售增长41倍、招聘增长41倍、营销增长26倍,相比之下工程岗位增长约5倍。这里说的是增长速度,并不代表这些部门的绝对Codex用户已经超过工程。

更早的OpenAI内部数据也显示,到2026年4月左右,Legal、Finance和Recruiting已经开始把Codex作为主要AI工作工具;非开发者的Codex采用速度甚至明显快于开发者。

这说明真正发生变化的可能不是:

更多非程序员开始“写代码”。

而是:

Codex正在从Coding Agent,逐渐变成General Execution Agent。


一、为什么Codex最先从程序员开始?

软件工程其实天然适合Agent。

因为代码世界拥有几个非常重要的条件:

Context清楚 ↓ Repository可读取 ↓ 任务可以拆分 ↓ 工具可以调用 ↓ 测试能够验证

比如:

修复登录失败Bug。

Agent可以:

读取Issue ↓ 搜索代码 ↓ 定位问题 ↓ 修改 ↓ 运行测试 ↓ 检查结果

这是一条非常清楚的执行链。

OpenAI在最新企业研究中也提到,软件工程成为Agent早期采用中心并不偶然:代码库能够提供明确Context,测试又能让结果更容易被验证。

换句话说:

软件工程不是因为“代码最适合AI生成”,而是因为“软件工作最容易形成可验证的Agent Loop”。


二、真正让Codex走出程序员圈的,不是“它会不会代码”

如果Codex只能:

生成代码,

那它确实很难走出研发部门。

但Agent真正的工作链已经变成:

Understand ↓ Plan ↓ Use Tools ↓ Transform Data ↓ Create Artifact ↓ Verify

这里真正核心的能力其实不是:

Coding。

而是:

Execution。

例如法务人员并不一定需要让Codex开发一个软件。

他可能需要:

读取合同 ↓ 提取关键条款 ↓ 对照Policy ↓ 整理风险点 ↓ 生成Review材料

销售可能需要:

读取CRM ↓ 分析客户 ↓ 整理历史沟通 ↓ 生成账户研究 ↓ 准备Follow-up

招聘可能需要:

整理候选人资料 ↓ 分类 ↓ 结构化面试反馈 ↓ 生成招聘报告

这些工作虽然没有传统意义上的“编程”,但都有共同结构:

多步骤 + 多来源 + 明确交付物。

这正是Agent擅长的任务形态。


三、Coding Agent正在变成“工作执行器”

传统ChatGPT解决的是:

告诉我答案。

Agent解决的是:

帮我把事情推进下去。

两者差别非常大。

传统模式:

Human ↓ Ask ↓ AI ↓ Answer

Agent模式:

Human ↓ Goal ↓ Agent ↓ Tools ↓ Work ↓ Deliverable

OpenAI把目前企业AI的变化直接概括成:

从Assistance走向Execution。

截至2026年6月,在企业客户中,Codex产生的输出Token已经占ChatGPT与Codex合计输出Token的64%。官方同时说明,Agent任务通常更长、步骤更多,所以这个64%不能简单解释成64%的企业工作已经由Codex完成,但它确实反映出企业正在把更多长任务和多步骤任务交给Agent。

所以Codex真正扩张的不是:

编程场景。

而是:

任务执行场景。


四、为什么法务增长会达到108倍?

这个数据很容易被误解。

它并不是说:

Codex现在主要被律师使用。

更准确的理解是:

法务从一个非常低的起点开始快速进入Agent工作模式。

而法务其实天然存在很多适合Agent的工作。

例如:

合同 ↓ 条款分类 ↓ 风险分析 ↓ Policy对照 ↓ 差异整理 ↓ Review材料

传统情况下,这些工作大量依赖:

搜索;

复制;

整理;

对照;

格式化。

人真正最有价值的部分其实是:

法律判断。

如果Agent能够承担前面的:

信息处理;

材料准备;

结构化整理,

人的注意力就可以更多集中到:

Risk Interpretation Decision

所以Agent真正改变的并不是:

AI代替律师判断。

而是:

律师是否还需要亲自完成每一个低层级执行步骤。


五、销售为什么也会快速Agent化?

销售看起来距离Coding更远。

但仔细看销售工作,会发现大量任务其实非常Agent-friendly。

比如一个销售准备客户会议。

传统流程可能是:

打开CRM ↓ 查客户官网 ↓ 查历史邮件 ↓ 找旧Proposal ↓ 整理客户背景 ↓ 准备Meeting Notes

大量时间都花在:

Information Assembly。

如果Agent可以连接正确Context和工具,

就可以变成:

Customer ↓ CRM ↓ Past Communication ↓ Playbook ↓ Agent ↓ Account Brief

OpenAI最新企业数据也专门举例说明,销售类Plugin可以把团队Playbook和CRM连接起来,让Agent利用最新客户信息及历史Proposal生成针对性的回复材料。

所以销售Agent真正减少的是:

Context Gathering Cost。


六、招聘为什么也特别适合Agent?

招聘流程本质上也包含大量结构化步骤:

Resume ↓ Candidate Profile ↓ Interview Notes ↓ Scorecard ↓ Feedback ↓ Decision Support

真正困难的地方往往不是:

读取一份简历。

而是:

大量资料分散在不同地方;

不同面试官写法不同;

信息需要统一整理;

最终还需要形成可以Review的材料。

Agent最大的价值就是:

把这些:

Scattered Inputs

转成:

Structured Workflow。

所以招聘人员最终可能越来越少手动完成:

搬运信息;

整理格式;

重复总结。

而更多关注:

候选人判断;

岗位匹配;

面试质量。


七、这其实暴露了一个更大的趋势:知识工作越来越像“软件任务”

过去我们会认为:

软件工作和知识工作差别很大。

但Agent进入以后,二者在系统层面反而越来越像。

软件任务:

Input ↓ Repository ↓ Tools ↓ Execution ↓ Test ↓ Result

知识工作:

Input ↓ Documents / Data ↓ Tools ↓ Execution ↓ Review ↓ Deliverable

真正的区别只是:

软件工程用Test验证。

知识工作可能使用:

Policy;

Source;

Rubric;

Human Review

进行验证。

所以Agent时代真正重要的问题变成:

能不能把知识工作定义成一个可执行、可验证的Workflow?

一旦可以,

它就开始具备Agent化条件。


八、OpenAI内部的变化更能说明这个方向

OpenAI今年6月公布的内部研究显示:

Codex最早当然由工程师大规模使用,但之后Legal、Finance和Recruiting快速跟上。到2026年4月左右,这几个非工程部门也开始把Codex作为主要AI工具;内部平均律师或招聘人员超过85%的输出Token已经来自Codex而不是ChatGPT。

更值得注意的是:

非开发用户不只是拿Codex做“文本工作”。

OpenAI表示,非技术人员还经常用Codex完成一些传统上超出自身岗位描述的技术执行,比如:

自动化;

数据转换;

内部工具;

Debug;

结构化分析。

这意味着Agent还在改变另一件事:

Job Boundary。


九、Agent正在降低“跨岗位执行”的门槛

过去一个销售如果想:

自动处理数据;

写脚本;

搭一个内部小工具,

通常需要找:

数据团队;

工程团队;

运营团队。

现在可能变成:

Business User ↓ Describe Goal ↓ Agent ↓ Code / Tool / Data ↓ Result

这并不意味着所有人突然变成程序员。

真正发生的是:

代码正在从专业身份,逐渐变成Agent使用的一种执行工具。

对用户来说,他可能根本不关心Agent是否写了Python。

他真正关心的是:

报告有没有生成?

数据有没有整理好?

Workflow有没有跑通?

所以:

Code

越来越可能从:

User-facing Skill

变成:

Agent Internal Tool。


十、这也是为什么“Codex”这个名字正在变得比“Coding”更宽

如果Agent最终完成的是:

Research Analysis Automation Documents Data Tools

那么代码只是完成这些任务的一种手段。

比如:

为了分析销售数据,

Agent可能自己写一段Python。

为了生成运营Dashboard,

Agent可能创建一个简单Web页面。

为了批量处理合同,

Agent可能自动写脚本。

最终用户交给Agent的是:

Goal。

Agent内部自己决定:

是否需要Code。

于是:

User Task ↓ Agent ↓ Maybe Code ↓ Outcome

而不是:

User ↓ Ask for Code

这就是Coding Agent走向General Execution Agent的重要一步。


十一、ChatGPT Work和Codex之间的边界也会越来越值得关注

OpenAI最新企业研究在描述“从asking到doing”时,同时提到了ChatGPT Work和Codex:前者可以帮助知识工作者跨来源收集材料、创建交付物,后者则继续承担更Agent化的执行任务。

这意味着未来真正的分工可能不再按照:

程序员 / 非程序员

划分。

而更可能按照:

任务类型

划分。

比如:

Conversation Research Document Work Technical Execution Automation

不同任务进入不同执行路径。

用户并不一定需要知道:

后台到底是哪一个产品或Agent完成。


十二、真正重要的单位正在从“岗位”变成“Task”

传统软件通常围绕岗位设计:

CRM给销售。

IDE给工程师。

ATS给招聘。

合同系统给法务。

Agent时代可能出现一种新的结构:

Task ↓ Context ↓ Tool ↓ Agent

例如:

“分析一个客户”

可以来自销售。

“分析一个供应商”

可能来自采购。

“分析一个候选人”

来自招聘。

虽然岗位不同,

底层Workflow却可能非常类似:

Gather ↓ Compare ↓ Reason ↓ Produce ↓ Review

所以Agent最终可能越来越围绕:

Work Pattern

而不是:

Job Title

设计。


十三、为什么非工程部门增长速度反而可能更快?

工程师本来就是Codex最早的一批重度用户。

因此工程部门已经拥有较高基数。

所以从2月至今工程增长5倍,而法务增长108倍,并不能直接说明法务现在的绝对使用量高于工程。OpenAI明确将这些数字用于说明Agent采用正在从软件工程快速向其他知识工作职能扩散。

但另一方面,

非工程部门确实拥有巨大的:

未Agent化Workflow存量。

过去这些任务主要靠:

手工;

Excel;

Email;

文档;

人工协调。

一旦Agent能够进入,

增长空间自然很大。


十四、真正决定非工程Agent能不能规模化的是Verification

软件工程之所以Agent化早,

一个重要原因就是:

测试。

代码改完:

Run Test

通过还是失败相对清楚。

知识工作更难。

例如Agent写了一份:

市场研究;

合同分析;

候选人报告。

什么叫:

正确?

所以知识工作要真正Agent化,

必须建立新的Verification Layer。

例如:

法务:

Policy Source Clause Reference Human Review

销售:

CRM Data Playbook Source Evidence Manager Review

招聘:

Scorecard Defined Criteria Structured Evidence Human Decision

所以未来真正的竞争点可能是:

谁能把模糊知识工作变成可验证Workflow。


十五、这也是为什么Skills和Plugins会越来越重要

Agent从程序员圈扩散以后,

最大的挑战就是:

通用模型并不知道:

你公司的销售标准是什么;

法务Policy是什么;

招聘Scorecard是什么;

市场研究流程是什么。

所以必须加入:

Company Context + Tools + Rules + Workflow

OpenAI最新数据显示,在AI使用最深的Frontier企业中,每周活跃用户使用Plugins和Skills的比例都明显高于典型企业。官方认为,连接公司Context、工具和可重复Workflow,是企业从AI访问走向更深Agent化的重要基础。

换句话说:

General Agent

真正进入企业以后,

最终一定会变成:

Company-specific Agent。


十六、未来的岗位能力可能出现一个很大的变化

以前岗位能力主要分两类:

Domain Knowledge + Software Skill

例如销售需要:

懂客户;

会CRM。

法务需要:

懂法律;

会合同系统。

未来可能再增加一层:

Agent Delegation Skill

也就是:

知道:

什么任务适合交给Agent;

需要哪些Context;

哪些步骤可以自动;

怎样判断结果;

什么时候必须人工接管。

这可能比:

“会不会写Prompt”

更重要。


十七、程序员也不会因此失去优势

Codex走出程序员圈,

并不代表工程师的重要性下降。

恰恰相反。

因为Agent越进入各部门,

企业越需要有人解决:

工具;

数据;

权限;

Workflow;

Verification;

Integration。

也就是说:

过去工程师主要写:

Business Software。

未来越来越多工程工作可能变成:

Agent Infrastructure。

比如:

为销售Agent接CRM;

为法务Agent建立文档检索;

为招聘Agent设计数据接口;

为Agent建立安全边界和审计。

所以程序员的位置可能从:

唯一能写代码的人

逐渐变成:

构建整个Agent执行环境的人。


十八、企业组织可能出现新的“Agent Layer”

传统组织:

Sales Legal Recruiting Marketing Engineering

每个部门拥有自己的工具。

未来中间可能增加一个共享层:

Sales Legal ↘ ↙ Agent Layer ↗ ↖ Recruiting Marketing

这个Agent Layer提供:

共享模型;

工具;

数据连接;

Skills;

Governance;

Verification。

各部门只需要在上面沉淀:

自己的Workflow。

这会让企业AI从:

很多独立AI使用案例

走向:

一套统一Agent基础设施。


十九、真正的变化不是“人人都会编程”

很多人看到Codex进入法务、销售和招聘,

很容易下一个结论:

AI让所有人都可以写代码了。

这个判断其实太窄。

更准确的是:

AI让更多人能够直接调度数字执行能力。

代码只是其中一部分。

真正重要的是:

过去员工需要找另一个专业团队才能完成的事情,

现在可能可以先交给Agent。

所以Agent真正降低的是:

Execution Barrier。


二十、未来知识工作的基本结构可能越来越相似

无论你是:

工程师;

律师;

销售;

招聘;

市场。

很多工作最终都会变成:

Goal ↓ Context ↓ Agent ↓ Tools ↓ Execution ↓ Evidence ↓ Human Judgment

不同岗位真正保留下来的核心差异,

可能越来越集中在:

Domain Judgment

而大量:

整理;

执行;

转换;

检索;

生成

则越来越多由Agent承担。


最后

Codex最早从软件工程开始,

是因为软件世界天然拥有:

清楚Context;

工具;

执行环境;

测试;

Verification。

但OpenAI最新企业数据已经显示,Agent采用正在快速向法务、销售、招聘和营销等知识工作扩散:自2026年2月以来,企业Codex周活用户在法务增长108倍、销售和招聘增长41倍、营销增长26倍,而工程增长约5倍。

真正值得关注的不是这些倍数本身。

而是背后的方向:

Coding Agent ↓ Task Agent ↓ Execution Agent ↓ General Knowledge Work

未来Codex真正的边界可能越来越不由:

“会不会写代码”

决定。

而由:

这个工作能不能被拆成一个拥有Context、Tools、Execution和Verification的Agent Workflow。

一旦可以,

它就不再只是程序员的工作。

所以Codex真正走出程序员圈,并不是因为:

所有人都开始编程。

而是因为:

编程正在变成Agent内部的一种执行能力。

员工真正交给Agent的是:

任务。

Agent内部自己决定:

需要搜索;

需要分析;

需要写代码;

还是需要调用工具。

从这个角度看,

Coding Agent真正的下一阶段,也许已经不只是:

写更多代码。

而是逐渐变成企业里一层新的:

General Execution Layer。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型,整理了稳定的AI会员订阅渠道。

http://www.jsqmd.com/news/1389386/

相关文章:

  • Dev-C++配置SFML全攻略:解决版本兼容与链接错误
  • 2024年企业网站建设建议:从零到一的实战避坑指南,打造高转化流量入口
  • 高可靠AI Agent架构设计:用工程化思维驾驭大模型的不确定性
  • 深圳led网站建设:如何通过专业的数字视觉营销,让你的品牌在流量池中脱颖而出
  • sarscape报错:DATA FORMATTING ANOMALY
  • SQL优化与安全实战:从执行计划到参数化查询的完整指南
  • GitHub Copilot 能换成本地吗?深入解析本地化替代方案
  • 石家庄网站建设加王道下拉如何打造企业官网的高转化逻辑与实战策略指南
  • 2026年合肥漏水维修服务评测:哪家更值得信赖?
  • 百度输入法皮肤制作全攻略:从iOS与Android适配到打包分发
  • 从纯方位无源定位到协同控制:无人机编队数学建模核心解析
  • 基于AI Agent的自动化开发流水线:从CI/CD到智能运维的实践
  • Spring Boot文件上传服务:从安全风险到生产级实现
  • JavaWeb用户管理系统实战:从Servlet到JSP的MVC架构全解析
  • 从皮肤文件规范到工作流:网易我的世界自定义皮肤上传全指南
  • Rust构建PHP虚拟机:AI辅助的编译原理与系统编程实践
  • 从机器人大会到开发实践:AI+ROS2+仿真构建智能体应用全流程
  • 轻薄本本地部署GPU加速Spark:环境搭建与实战指南
  • 从输入上下文到智能体:掌握AI交互四大核心概念,打造高效工作流
  • TypeScript成为AI应用开发标配:从GitHub趋势看2026前端技能重塑
  • 还在手动解包PKG和DMG?Brigadier一条命令搞定Mac的Boot Camp驱动
  • 基于RWEQ模型的2000-2025年中国逐年250米分辨率实际风力侵蚀数据集
  • 2026甄选:北京经开区药企车间改造品牌机构实力观察 - 卓企推荐
  • ChatGPT Plus / Pro 用户的 Codex 进阶实战:从 CLI 配置到 Agent 工作流、多文件重构与用量控制的完整指南
  • 助力东莞本土企业腾飞:美丽寮步网站建设高性能背后的技术逻辑与商业价值
  • Rolldown:基于Rust的高性能前端构建引擎解析与迁移指南
  • Claude Code架构深度解析:从AI编程工具到现代Web应用设计
  • 揭秘MoE与注意力机制:从DeepSeek-V3到开源架构的工程实践
  • 混合RAG与智能体架构:解决科学设施运维知识检索与决策难题
  • AI Agent技能评估:从主观验收到系统化Eval方法论实践