OpenAI开源Codex Harness:真正改变的不是聊天框,而是AI Agent生产系统
2026/8/23 7:25:29 网站建设 项目流程

写在前面

欢迎大家关注Rocky的公众号:WeThinkIn
欢迎大家关注Rocky的知乎:Rocky Ding
《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源:【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book,欢迎大家Star~

Rocky最新撰写的10万字AI Agent(AI智能体)深入浅出全维度解析文章:深入浅出完整解析AI Agent(AI智能体)的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群(涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识)欢迎大家加入:https://t.zsxq.com/33pJ0


大家好,我是Rocky。

核心导读

2026年8月19日,OpenAI发布《Codex as a platform: build on the open agent harness》,两天后,中文技术社区把这件事概括成了一个更有传播力的标题:OpenAI把Codex的“完整发动机”开源了,AI Agent从此零门槛。

这句话抓住了事件的冲击力,却也容易把最值得讨论的部分说浅。

Rocky认为,Codex Harness开源真正降低的,不是“调用一个模型”的门槛,而是构建Agent执行系统的工程门槛。它把对话状态、长任务上下文、工具调用、沙箱、审批、流式事件和跨轮次工作这些原本散落在产品代码里的能力,收束成一套可以检查、嵌入和适配的软件基础设施。

但“开源执行系统”不等于“交付可靠业务结果”。OpenAI明确写道,开源的是Harness和集成表面,模型访问与托管服务仍然是分开的。从这套基础设施走到真正可用的企业产品,中间仍隔着数据契约、权限治理、离线与在线评测、异常回滚、成本控制,以及最容易被忽略的组织责任。

所以,这篇文章不准备重复“开源三大组件”的产品清单,而是回答四个更本质的问题:Codex到底开源了什么;Harness为什么会实质性改变Agent表现;app-server为什么比套壳聊天框更接近AI-native产品;以及开源之后,真正的护城河会转移到哪里。

一、先校准事件:OpenAI到底开源了什么

很多媒体将这次发布描述为“把驱动顶级AI智能体的发动机免费送给大家”,并进一步推导出“AI Agent零门槛”“彻底打通企业落地最后一公里”。这些表达适合作为行业情绪的观察样本,但不能直接当作技术事实。

从OpenAI官方文章和当前公开仓库看,更准确的说法是:OpenAI正在把Codex中可复用的Agent Harness和产品集成界面开放为平台能力。公开范围包括Codex CLI、codex exec、官方SDK和codex app-server等组件;openai/codex仓库采用Apache-2.0许可证,开发者可以检查、修改和用于商业项目。

这里必须保留三条边界。

第一,开源的是模型外侧的Harness与集成表面,不是模型权重本身。模型调用仍依赖相应的访问方式,托管服务也不因仓库开放而自动变成本地基础设施。

第二,公开仓库能证明代码里存在什么,却不能证明所有Codex产品表面与全部内部服务都被等比例复刻出来。App、CLI、IDE扩展和云端能力共享技术血缘,不代表每一个后台实现都完整包含在同一个公开仓库中。

第三,Apache-2.0解决的是代码许可,不解决生产可用性。能商用、能二次开发,与能满足SLA、审计、灾备、数据主权和责任追踪,是两组完全不同的问题。

这三条边界不是给事件降温,而是为了看清它真正有价值的地方:OpenAI没有只开放一个“调用模型的薄封装”,而是在开放一个相对完整的Agent运行时和产品协议层。

二、Harness的本质:模型外侧的执行系统

很多Agent Demo的基本结构是:拼接Prompt,调用模型,解析回复,再根据回复执行一个工具。这个循环足以展示“AI会做事”,却远不足以支撑持续运行的业务系统。

真实任务会不断提出更难的问题:上一轮发生了什么,下一轮该继承哪些状态;模型准备执行命令时,当前目录和网络权限是什么;工具运行了十分钟,界面如何持续展示进度;上下文超长后,哪些历史必须保留;执行一半失败了,能否重试或恢复;修改数据库、发送邮件、重新订舱之前,谁来审批;最终结果如何写回权威业务记录。

这些问题都不属于“再写一段更好的Prompt”。它们共同构成了Harness。

从系统角度看,一个可工作的Agent可以近似拆成四层:

层级主要职责典型失败
模型层理解、推理、生成下一步动作推理错误、幻觉、指令偏移
Harness层状态、上下文、工具、沙箱、审批、事件循环状态丢失、越权、重试失控、上下文污染
产品层界面、业务语义、工作流和人工决策场景不匹配、交互低效、责任不清
业务系统层权威数据、规则、交易与审计记录数据冲突、脏写、不可回滚、合规风险

模型决定单步能力的上限,Harness决定这份能力能否被稳定调度,产品层决定能力是否进入用户原有工作流,业务系统层则决定动作是否真实有效、可审计、可追责。

这也是为什么Agent产品不能只比较模型榜单。相同模型放进不同Harness,最终表现可能差别很大;同一Harness嵌入不同业务数据和审批体系,产品价值同样可能完全不同。

三、三层集成不是功能清单,而是三种系统边界

OpenAI给出了三个主要集成层级:codex exec、官方Codex SDK和codex app-server。表面看,它们只是从简单到复杂的三种调用方式;本质上,它们对应三种不同的责任划分。

1. codex exec:有边界的非交互任务

codex exec适合脚本、CI任务和一次性后台作业。宿主系统给出明确任务与执行边界,Agent完成工作后返回普通文本或结构化结果。它最重要的价值不是“在命令行里聊天”,而是让Agent成为流水线中的一个可调用节点。

这种方式适合代码检查、批量迁移、报告生成、仓库维护等结果相对清晰的任务。它的优点是集成成本低、生命周期短、容易放进现有自动化;局限也很明显:如果产品需要持续会话、细粒度事件、运行中干预和复杂审批,仅靠一次命令就会很快触顶。

2. Codex SDK:把任务生命周期交给应用代码

SDK适合需要用程序启动、恢复和流式接收Codex任务的应用。开发者不再只等待一个最终字符串,而是可以维护线程,观察执行过程,并把Agent结果接回自己的程序逻辑。

SDK降低的是“用代码组织Agent工作流”的成本。它非常适合内部平台、研发工具和后台服务,但SDK仍然会对常见工作流做抽象。当产品需要直接掌握线程、回合、事件、工具和审批的完整生命周期时,app-server提供了更底层的控制面。

3. codex app-server:把Agent变成产品内部的运行时

codex app-server面向的不是“我想调用一次Codex”,而是“我的产品本身需要一个持续存在的Agent运行时”。宿主应用连接本地Codex进程,保持会话,流式接收事件,中断任务,暴露自有工具,并处理审批请求。

官方架构图最值得看的是边界,而不是箭头:产品拥有界面、业务上下文与业务规则;应用自有MCP服务连接权威数据和业务动作;app-server负责Agent循环与沙箱化执行。审批结果再回到产品控制面。

这意味着应用不必把自己改造成一个聊天框。安全团队仍然看告警和受影响服务,客服仍然看账号历史和产品日志,运营仍然看订单、地图和队列。界面不是Agent之外的装饰,而是业务上下文的可视化载体,也是人类判断与责任落点。

四、Thread、Turn、Item:Agent产品首先是状态机

当前app-server文档把生命周期抽象成三个核心对象:

  • Thread是一段用户与Agent之间的持续会话,内部包含多个Turn;
  • Turn是从一次用户输入开始,到Agent完成或被中断的一次运行;
  • Item是Turn中的具体事件单元,包括用户输入、Agent推理、Agent消息、Shell命令、文件修改等。

这组抽象看起来朴素,却是Agent从Demo走向软件系统的关键。只要执行过程被表达成稳定状态和事件,宿主应用才有机会做持久化、恢复、审计、回放、监控和测试。

一条典型链路是:客户端先发送initialize完成握手,再用thread/start创建会话,或用thread/resume恢复既有会话;随后通过turn/start提交本轮任务。执行期间,客户端持续接收item/starteditem/completed、消息增量和工具进度;任务自然结束时收到turn/completed,需要人为停止时则调用turn/interrupt

这不是一套为了“实时打字效果”设计的通知机制。对生产系统而言,流式事件至少承担四种职责:让用户知道Agent正在做什么;让应用在危险动作发生前介入;让监控系统定位卡点与失败;让最终结果能回溯到具体工具调用和文件修改。

公开文档还显示,app-server默认可通过stdio传输JSONL,并提供双向、类似JSON-RPC的协议;它能生成与当前版本匹配的TypeScript类型和JSON Schema。服务内部使用有界队列,入口饱和时返回可重试的-32001过载错误,并建议客户端采用带抖动的指数退避。

这些细节说明,OpenAI开放的不是一个只有“输入Prompt、输出Answer”的接口,而是一套开始认真处理背压、模式契约和客户端恢复策略的产品协议。

五、上下文压缩:不是删聊天记录,而是管理任务状态

Agent执行时间一长,最先遇到的往往不是模型不会推理,而是上下文越来越大。代码、日志、命令结果、工具响应和中间解释持续堆积,如果简单截断,关键约束会丢;如果全部保留,成本、延迟和噪声又会不断上升。

上下文压缩真正困难的地方,不是“把一万字缩成一千字”,而是区分三类信息:必须跨轮次保留的任务约束,已经完成但仍影响后续决策的状态,以及可以安全丢弃的过程噪声。压缩结果还必须继续支持工具调用、审批和后续恢复,而不是生成一段看似通顺、却无法继续工作的摘要。

在本文固定的仓库快照中,compact.rs包含压缩前后Hook、压缩元数据、模型客户端会话、自动压缩窗口与退避等实现线索。这至少能证明:压缩在Codex中不是一个前端摘要按钮,而是运行时生命周期的一部分。

OpenAI官方文章给出的ARC-AGI-3结果进一步说明了Harness的重要性:在该实验中,保留推理与上下文压缩让GPT-5.6 Sol的得分从13.3%提高到38.3%,同时把输出Token降低到原来的六分之一。

这组数字很强,但它只能证明:在这个模型、这个任务和这组Harness调整下,状态保留与上下文管理显著改变了结果。它不能直接证明Harness让所有模型“智力提高三倍”,也不能证明所有企业任务都会获得相同收益。ARC-AGI-3与真实业务流程之间,还隔着工具可靠性、数据质量、权限配置、用户行为和成本约束。

严谨的结论应该是:评估Agent时,模型与Harness不能再被当作两个互不相关的变量。Benchmark需要记录的不仅是模型名,还应记录上下文策略、工具协议、重试规则、执行预算和终止条件。否则所谓“模型能力对比”,很可能混入大量运行时差异。

六、工具与审批:权限不是一个开关,而是一条决策链

Agent能调用工具之后,产品价值才开始出现,风险也在同一刻出现。

一个读取日志的工具、一个修改配置的命令、一个向客户发信的接口和一个重新订舱的动作,不能共享同一套粗粒度权限。企业系统需要回答:谁发起了动作,Agent依据了什么上下文,命中了哪条规则,在哪个沙箱执行,为什么需要审批,审批者看到了什么,执行结果如何写回,失败后如何补偿。

当前公开源码中的exec_policy.rs展示了命令规则匹配、Allow等决策、危险命令识别、审批需求、规则更新以及网络规则处理。这不等于开箱即用的企业治理方案,但它说明权限与审批已经进入运行时,而不是全部留给上层产品临时拼接。

真正可靠的设计通常要把控制分成三层:

  1. 静态边界:文件系统、网络、环境、凭据和工具白名单,先从能力上限制Agent能接触什么;
  2. 策略判断:根据命令、资源、用户、任务与数据敏感度,决定允许、拒绝或请求审批;
  3. 业务审批:对会改变权威记录、产生外部承诺或不可逆后果的动作,由明确责任人确认。

很多Agent项目的问题,是把第三层做成一个“确认/取消”弹窗,却没有第一层和第二层。结果是审批者看不到充分上下文,系统也没有最小权限与可解释策略。Human-in-the-loop不是给风险动作加一个按钮,而是建立一条能让人真正承担判断责任的控制链。

七、Relay为何比“套壳聊天框”更接近AI-native产品

OpenAI用Relay演示了一种物流运营应用:用户先选择一票异常货物,再点击“Compare recovery”。应用把当前业务上下文交给Codex;Agent通过应用自有MCP工具读取最新数据,比较恢复方案;如果需要重新订舱,则必须由人审批;工具写回记录后,业务看板刷新。

这套交互的关键,不是界面比聊天框更漂亮,而是五类责任被放回了正确的位置:

  • 产品决定用户正在处理哪一个业务对象;
  • 业务系统提供权威数据与合法动作;
  • Harness管理Agent循环、状态和工具交互;
  • 人类对高后果动作保留最终决定权;
  • 写入完成后,权威记录而不是聊天历史成为事实来源。

这才是AI-native产品与聊天套壳的本质区别:不是有没有对话框,而是AI是否进入了可观察、可控制、可回写的业务闭环。

聊天框不会消失。它仍然适合开放探索、模糊问题和自然语言补充。但当用户已经站在订单、患者、告警、合同或代码变更面前时,让他重新描述屏幕上已有的上下文,本身就是一种产品退化。更好的设计是让业务对象成为主语,让Agent成为能调查、建议并在授权后执行的系统能力。

八、案例能证明落地可能性,不能替代独立评测

OpenAI官方文章列出了一些公开实践:Cisco在Cisco Cloud Control内部使用Codex SDK构建App Builder;Thrive Holdings与Crete把Codex用于税务准备工作流,其试点处理了7,000份申报材料,并称准备时间缩短约三分之一。

这些案例的价值,是证明Codex Harness不只服务于通用编程助手,也可以嵌入云管理和专业服务流程。但它们仍属于OpenAI及合作方披露的案例信息,不是跨客户、跨场景、由独立机构完成的通用Benchmark。

企业评估时至少还要补齐五组指标:任务成功率与人工接管率;错误动作和高风险近失事件;平均完成时长与尾延迟;Token、工具、计算和人工审批的总成本;以及上线前后对业务结果的真实增量。只看“处理了多少任务”或“节省了多少时间”,很难判断样本选择、基线流程、返工成本和失败分布。

对Agent产品尤其要关注尾部风险。平均准确率达到95%,如果剩余5%集中在高价值客户、敏感数据或不可逆动作上,系统仍然不具备自动执行资格。生产可靠性不是把平均分继续向上刷一点,而是识别哪些任务可以自动化,哪些任务必须降级,哪些动作永远需要双重确认。

九、从开源基础设施到生产系统,还缺哪五块

Codex Harness让Agent底座变得更可复用,但不会替企业完成最后的系统工程。Rocky认为,真正决定落地质量的是下面五块。

1. 数据契约

Agent看到的不是“公司知识”,而是具体字段、版本、时间戳、来源与权限。MCP可以标准化工具暴露方式,却不会自动保证数据正确。每一个工具都需要明确输入输出Schema、幂等语义、错误码、数据新鲜度和权威来源。

2. 权限与责任

沙箱解决执行环境边界,审批解决部分高风险动作,但企业还需要身份映射、职责分离、最小权限、密钥管理、操作留痕和责任人制度。不能因为动作由Agent建议,就让责任主体消失。

3. 评测与可观测性

离线评测要覆盖正常样本、边界样本和对抗样本;在线系统要观察每个Turn与Item的延迟、失败、工具调用、审批和回滚。只统计最终回答好不好,会丢失Agent系统最重要的过程证据。

4. 回滚与补偿

文件修改可以用版本控制恢复,数据库写入、邮件发送、付款和业务承诺却未必可逆。工具设计必须优先支持预览、Dry Run、幂等键、事务或补偿动作。没有回滚设计的Agent,只是在用更自然的语言触发传统事故。

5. 组织工作流

Agent往往跨越研发、产品、业务、安全与合规。谁定义工具,谁批准权限,谁维护评测集,谁对错误结果负责,必须在上线前被写清楚。技术上的Human-in-the-loop,最终要落到组织里的Owner-in-the-loop。

十、对开发者、企业、创业者和投资人的真正含义

对开发者:从“会调模型”转向“会构建可恢复系统”

模型API调用会越来越标准化,Harness也会逐渐成为公共基础设施。更稀缺的能力,是把业务对象变成可靠工具,把任务拆成可观察状态,设计权限与审批,建立评测、回滚和成本治理。未来的Agent工程师,更像分布式系统工程、产品工程与AI工程的交叉角色。

对企业:先选闭环,再选模型

企业不应该从“我们要接入Codex”开始,而应该从一个可定义、可评测、可回滚的业务闭环开始。先找清楚权威数据在哪里、可执行动作是什么、风险边界在哪里,再决定使用exec、SDK还是app-server。技术选型应服务于责任边界,而不是反过来。

对创业者:Harness开源会削弱薄封装,却放大垂直系统价值

如果产品的核心只是模型调用、通用聊天UI和几个工具编排,底层能力开放会快速压缩差异化。相反,行业数据契约、专有工作流、交付能力、用户信任、评测资产和渠道会变得更重要。

工具不是护城河,单纯的Harness也不是护城河。能够把模型、执行系统和行业责任接成闭环,才可能形成跨周期价值。

对投资人:不要把“有Agent”当成技术壁垒

更值得追问的是:项目是否掌握权威数据入口;工具调用是否真的进入交易或生产流程;高风险动作由谁批准;错误能否被发现与补偿;随着基础模型和开源Harness升级,项目的差异化是被吸收,还是继续积累。

Harness开源降低了供给侧成本,也会让Agent项目数量进一步增加。但数量增加不等于商业确定性增加。基础设施越成熟,市场越会惩罚只有Demo、没有交付闭环的项目。

结语:Agent竞争正在从模型调用,进入生产系统

Codex Harness开源真正释放的,不是一套更方便的聊天组件,而是一种新的软件分工:模型负责理解与推理,Harness负责状态与执行,产品负责业务界面和规则,权威系统负责数据与交易,人类负责高后果决策。

这套分工一旦稳定下来,Agent就不再只是屏幕右下角的对话入口,而会成为工作流里的基础设施。

但基础设施开放从来不会消灭工程难题,它只会把竞争推向更深处。过去大家比较谁能更快接上模型,接下来要比较谁能定义更好的数据契约,谁能把权限和审批做成可靠控制面,谁拥有真实评测与失败样本,谁能把动作写回业务并在出错时恢复。

Rocky的最终判断是:OpenAI降低了Agent循环的重复建设成本,却没有替任何团队交付业务结果。聊天框正在退回一种交互组件,真正的主战场,是Agent生产系统。

推荐阅读

Rocky一直在运营技术交流群(WeThinkIn-技术交流群),这个群的初心主要聚焦于技术话题的讨论与学习,包括但不限于算法、开发、竞赛、科研以及工作求职等。群里有很多人工智能行业的大牛,欢迎大家入群一起学习交流~(请添加小助手微信Jarvis8866,拉你进群~)

1. 深入浅出完整解析AI Agent(AI智能体)的核心基础知识

2025年可以说是AI Agent全面落地应用的元年,因此Rocky在持续撰写对AI Agent的全维度解析文章:

深入浅出完整解析AI Agent(AI智能体)的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

Rocky对扩散模型的本质原理与和核心基础知识进行了全面系统的深入浅出分析讲解,同时不断跟进补充扩散模型的最新技术发展,希望能给大家带来帮助:

深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream(即梦)、Z-image、GLM-Image核心基础知识

Rocky对AIGC时代“中场时刻”之后的主流AIGC创作大模型的核心基础知识进行了全面系统的深入浅出分析讲解,力求让大家通俗易懂理解AIGC时代的技术浪潮的本质价值:

入浅出完整解析FLUX.2、Seedream(即梦)、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

Rocky对FLUX.1 Kontext和FLUX.1 Krea的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

Rocky对DeepSeek系列模型的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3(SD 3)和FLUX.1系列核心基础知识

Rocky对Stable Diffusion 3和FLUX.1的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion 3(SD 3)和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL(SDXL)核心基础知识

Rocky对Stable Diffusion XL的核心基础知识作了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion XL(SDXL)核心基础知识

8. 深入浅出完整解析Stable Diffusion(SD)核心基础知识

Rocky对Stable Diffusion 1.x-2.x系列模型的核心基础知识做了全面系统的梳理与解析:

深入浅出完整解析Stable Diffusion(SD)核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

Rocky对Stable Diffusion中最为关键的U-Net结构进行了深入浅出的全面解析,包括其在传统深度学习中的价值和在AIGC中的价值:

深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA(Low-Rank Adaptation)模型核心基础知识

对于AIGC时代中的“ResNet”——LoRA模型,Rocky进行了深入浅出的全面讲解:

深入浅出完整解析LoRA(Low-Rank Adaptation)模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

AIGC图像创作开源社区已经形成以Stable Difffusion/FLUX为核心,ConrtolNet和LoRA作为首要AI辅助工具的变化万千的AIGC图像创作工作流。

ControlNet正是让AI图像创作社区无比繁荣的关键一环,它让AIGC图像创作过程更加的可控,更有助于广泛地将AIGC算法解决方案应用到各行各业中

深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

AI绘画和AI视频是两个互相促进、相互交融的领域,2024年无疑是AI视频领域的爆发之年,Rocky对AI视频领域核心的Sora、Seedance、Keling等大模型进行了全面系统的梳理与解析

深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

在AIGC时代中,Transformer为AI行业带来了深刻的变革。Transformer架构正在一步一步重构所有的AI技术方向,成为AI技术架构大一统与多模态整合的关键核心基座,大有一统“AI江湖”之势。Rocky也对Transformer模型进行持续的深入浅出梳理与解析:

深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

AIGC创作框架正是AIGC算法工作流的运行载体,目前主流的AIGC创作框架有ComfyUI、Diffusers、Stable Diffusion WebUI等。在传统深度学习时代,PyTorch、TensorFlow以及Caffe是传统深度学习模型的基础运行框架,到了AIGC时代,Rocky相信ComfyUI就是AIGC时代的“PyTorch”、Stable Diffusion WebUI就是AIGC时代的“TensorFlow”、Diffusers就是AIGC时代的“Caffe”

深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

在AIGC时代中,如何快速转身,入局AIGC产业?如何成为AIGC/LLM/AI Agent算法/开发工程师?如何在学校中系统性学习AIGC/LLM/AI Agent知识,斩获心仪的AIGC/LLM/AI Agent算法/开发offer?

Don‘t worry,Rocky为大家总结整理了全面的AIGC/LLM/AI Agent算法/开发工程师成长秘籍,为大家答疑解惑,希望能给大家带来帮助:

手把手教你成为AIGC/LLM/AI Agent算法/开发工程师,斩获AIGC/LLM/AI Agent算法/开发offer!

16. AIGC产业的深度思考与分析

2023年3月21日,微软创始人比尔·盖茨在其博客文章《The Age of AI has begun》中表示,自从1980年首次看到图形用户界面(graphical user interface)以来,以OpenAI为代表的科技公司发布的AIGC模型是他所见过的最具革命性的技术进步。

Rocky也认为,AIGC及其生态,会成为AI行业重大变革的主导力量。AIGC会带来一个全新的红利期,未来随着AIGC的全面落地和深度商用,会深刻改变我们的工作、生活、学习以及交流方式,各行各业都将被重新定义,过程会非常有趣。

那么,在此基础上,我们该如何更好的审视AIGC的未来?我们该如何更好地拥抱AIGC引领的革新?Rocky准备从技术、产品、商业模式、长期主义等维度持续分享一些个人的核心思考与观点,希望能帮助各位读者对AIGC有一个全面的了解:

深入浅出全面解析AIGC时代核心价值与发展趋势(2025年版)

17. AI算法工程师的独孤九剑秘籍

为了方便大家实习、校招以及社招的面试准备,同时帮助大家提升扩展技术基本面,Rocky将符合大厂和AI独角兽价值的算法高频面试知识点撰写总结成《三年面试五年模拟》之独孤九剑秘籍:

【三年面试五年模拟】AIGC时代的算法工程师的求职面试秘籍(持续更新中)

18. 深入浅出完整解析AIGC时代中GAN(Generative Adversarial Network)系列模型核心基础知识

GAN系列模型作为传统深度学习时代的最热门生成式Al模型,在AIGC时代继续繁荣,作为Stable Diffusion/FLUX系列大模型的“得力助手”,广泛活跃于AlGC图像创作的产品与工作流中:

深入浅出完整解析AIGC时代中GAN(Generative Adversarial Network)系列模型核心基础知识

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询