从 Codex Harness 拆到企业级 AI 架构,讲透技术 Harness、业务 Harness、AI 架构 Harness。

最近 Harness 这个词彻底火了。先是 DeepSeek 那边把 Harness 层开源,紧接着 OpenAI 把 Codex 的整个 Harness 层也全面开源出来。一时间朋友圈、技术群里全在聊 Harness。

但我在直播间做了一轮小调研，结果挺有意思：几乎所有人都能背出那个公式：Agent = LLM + Harness，可一旦追问"这里的 Agent 到底指谁"，公屏上的答案立刻五花八门。

这恰恰是问题所在。

这个公式本身没错，但它太粗了。粗到你把它背下来，对你明天要落地的那个智能体项目，不会产生任何帮助。

所以这篇文章我想做一件事：把 Harness 这个概念彻底拆开，拆成三层，并且把每一层"到底该由谁来建、建成什么样、有哪些工程约束"讲清楚。

如果你正在企业里落地 AI 应用：不管是智能客服、报告生成，还是 AI 原生产品等，这三层里至少有两层，是你躲不掉、也没人能替你建的。

一、先把定义钉死：Harness 到底是什么

我给 Harness 的定义只有一句话:

Harness = 为 AI Agent 建立安全的执行轨道。

注意"轨道"这个词。它不是围墙，不是把 AI 关起来；它是铁轨，是让高速运行的东西不出轨、不跑偏。这是理解 Harness 的第一个关键。

那么第二个关键问题来了，也是我在直播间抛给大家的灵魂拷问：

这句定义里的"AI Agent"，到底指的是谁？

有三种可能：

• Code Agent：比如 Codex、Claude Code 这类写代码的智能体;
• 业务 Agent：比如你正在做的智能客服、报告生成、智能投顾;
• 全局 Agent 架构：你整个企业级 AI 应用的运行时与生态。

公屏上 1、2、3 都有人扣。而正确答案是：三个都是。

于是就有了三层 Harness:

层级	服务对象	目的	产出物
技术 Harness	Code Agent	让 AI 稳定地"造出"东西	一个可稳定运行的 Agent / 服务
业务 Harness	业务 Agent	让造出来的东西稳定地"跑在线上"	一个可靠的运行时
AI 架构 Harness	全局 Agent 架构	让单个智能体长成一个生态	企业级 AI 应用架构

Codex Harness 属于哪一层？很显然，它属于最底下那层技术 Harness。

而绝大多数人对 Harness 的认知,恰恰只停留在这一层。这也是为什么很多同学看完 Codex 源码解析,依然不知道自己的项目该怎么改。

下面我们一层一层往上走。

二、技术 Harness：Codex Harness 的五层架构拆解

先说结论：Codex Harness 的目标，是生产出可稳定运行的 Agent 或服务。

它服务的对象既包括存量的微服务业务（比如“帮我给电商订单模块加一个删除功能”），也包括全新的 AI 原生应用（比如我们自己做的 AITutor，本身就是一个完整的智能体）。

整体架构可以拆成五层，一条主链路走下来是：

入口层 → App Server → Codex Core → Execution Layer → Workspace → （Feedback 回流）

2.1 第一层：入口层（User / IDE）

研发同学怎么用 Codex？无非三种方式：IDE 插件（VS Code 里直接集成）、CLI 命令行、或者通过 SDK 接进去。

这一层没什么复杂逻辑，它的唯一职责就是“接住人的意图”。

2.2 第二层 App Server：用户与 Codex 之间的桥梁

这一层是控制面，负责连接你的 UI 和底下的 Codex 内核。它有三个核心概念：

• Thread（会话/线程管理）：我这次操作 Codex，是开一个进程还是开一个线程？会话的生命周期怎么管？
• Turn（轮次管理）：用户输入的是自然语言，“帮我给电商客服的订单模块加个删除功能”。每一轮对话都需要独立管理。
• Item（事件管理）：这是最容易被忽略、但设计上最巧妙的一点。Codex 把执行过程中的所有事件（要用沙箱了、需要人工审批了、工具调用完成了）统一抽象成 Item，通过 App Server 推给 UI，让人看到、让人介入。

你在 Codex 右下角看到的那个“我需要用到某某工具，请授权”的弹窗，底层走的就是这条链路。

关键点：这一层不做任何推理。它是纯粹的翻译层和桥梁层，把人的输入翻译成 Codex 能理解的语言，再把 Codex 的事件翻译成人能看懂的界面。

很多团队自研 Agent 平台时，把会话管理、事件推送、审批交互一股脑塞进核心逻辑里，导致内核越来越臃肿。Codex 在这里做了一次非常干净的切分，值得抄。

2.3 第三层 Codex Core：心脏是 Agent Loop

这是整个架构最核心的一层。

不管是 Codex、Claude Code 还是国内的各家 Code Agent，它们的心脏都是同一个东西：Agent Loop。

Agent Loop 不属于 Workflow，它属于 Agent。而当前最主流的 Agent 范式，本质上就是ReAct：Planning（规划）、Action（执行）、Observation（观测）。

映射到 Codex 的架构图上，这个循环长这样：

Context → Model → Tool → Result
↑                        │
└──────  Feedback  ──────┘

我们把每一环拆开看：

① Context（上下文）：这一环装什么？

• 用户的原始 prompt（“帮电商系统加个删除功能”）；
• 可用的工具集、外部 MCP 服务；
• 存量系统的业务知识：业务术语表（用来消歧）、现有架构拓扑（用来做服务定位）、各模块的职责说明。

第三项恰恰是企业落地时最容易缺失、又最影响效果的部分。模型不知道你们公司把“履约单”叫什么，它就只能瞎猜。

② Model（推理）：本质在做 Planning。规划出要分几步、每步做什么。

③ Tool（工具调用）：把规划落成 Action。比如第一步“先拉取存量系统的架构拓扑图”。

④ Result（结果）：执行成功还是失败，这就是 Observation。

⑤ Feedback（反馈）：结果回流到下一轮 Context，进入下一轮决策。

2.4 一个容易被忽略的洞察：这个循环里，已经有“学习”了

我在直播间问了一个问题：Agent Loop 里，有没有“学习”这件事？

公屏上 1 和 0 都有。

答案是有的。

你的 Observation 结果，不管成功还是失败，都会 Feedback 到下一轮的 Context。这就是 Context 级别的 Learning。

Observation 的作用，本质上就是在做学习。所以这个循环天然带有一点“自主进化”的味道。

当然，只停留在 Context 级别的学习是远远不够的。完整的学习闭环至少有三个层级：

学习层级	载体	闭环周期	落地难度
Context 级学习	会话上下文	秒级（单次任务内）	低
知识库 / 本体级学习	领域知识沉淀	天级 ～ 周级	中
模型权重级学习	微调 / 后训练	周级 ～ 月级	高

业界现在普遍把“持续学习”看作下一代模型的核心命题。而对我们做落地的人来说，道理是一样的，只是学习的粒度和闭环周期不同，本质上都是在学习。

2.5 Agent Loop 之外：八个能力模块

真正跑复杂任务，光有那个最小循环肯定不够。Codex 的做法是在循环外面一圈一圈往上加能力：

模块	解决什么问题
Context / Memory	短期记忆 + 长期记忆
Skills / MCP	把业务知识、架构链路封装成可调用的技能与拓扑接口
State / Task	100 个任务逐一执行，第 10 步中断后要能断点续传
Multi-Agent	无依赖关系的任务拆给 SubAgent 并行
Approval / Policy	高风险操作的授权层（那个右下角弹窗）
Sandbox	独立 Worktree、独立容器、独立沙箱
Compaction / Persistence	上下文压缩 + 内存状态持久化到磁盘（防宕机丢状态）
Trace	全链路追踪：每一步规划调了什么、花了多少 Token、花了多少钱

这八个模块，每一个拿出来都是一套独立的工程。它们共同构成了 Codex Core。

这里我特别想强调 Skills 和 MCP 这一组。存量业务架构往往太复杂，复杂到你没法直接封成 Skill。这时候更务实的做法是：把架构链路变成一张 Graph，再通过 MCP 接口暴露出来，让 Agent 按需查询。这个思路在存量系统改造里非常好用。

2.6 第四层：Execution Layer（执行层）

Core 只负责决策，真正的执行落在这一层：

• Shell：调本地命令行
• Files：读写本地文件系统
• Git：对接内部 Git / GitHub
• MCP：调用内外部 MCP 服务
• Process / SubAgents：比如代码解释器。注意它是 Process（进程）而不是 SubAgent，这两个概念别混

2.7 第五层：Workspace + Feedback Loop

Workspace 说白了就是一个目录，存两样东西：Code（代码）和Tests（测试）。

但别小看第二样。写代码只是一半工作，评测与验收是另一半，而且往往是更重要的一半。Test Case 就放在这里。

最后，执行结果通过 Feedback Loop 回流到 Codex Core，驱动下一轮决策，闭环形成。

2.8 技术 Harness 小结

Codex Harness 的五条设计原则：模块化、可观测、可控安全、可扩展、持续进化。

一句话概括它的价值主张：

智能体的力量 = 记忆 + 推理 + 行动 + 反馈，形成持续进化的闭环系统。

但是，这一层你大概率不需要自己建。

为什么？因为 Codex、Claude Code 这些 Code Agent，只会把这一层做得越来越厚。你今天费力自研的东西，半年后可能就被官方能力覆盖了。

你真正躲不掉的，是接下来这两层。

三、业务 Harness：七层框架，每一层都是一道工程约束

假设技术 Harness 已经帮你造出了一个智能体。现在问题来了：

怎么把它推到线上，并且让它稳定地跑？

这就是业务 Harness 要解决的事。

我先说一个判断，这个判断很重要：

技术 Harness 大模型厂商会替你做，业务 Harness 大模型厂商永远吞并不了。

因为业务 Harness 和你的业务强耦合。你的退款规则、你的风控边界、你的审计要求、你的回滚预案，没有任何一个通用模型能替你定义。

很多同学一提 Harness 就以为是技术 Harness，这是最大的认知盲区。

3.1 业务 Harness 是什么

一句话：业务 Harness 是执行框架，它决定 AI 如何获得上下文、选择工具、执行命令、处理权限、验证结果、停止与上报。

它一共七层：

上下文装载层 → 工具层 → 计划层 → 执行层 → 验证层 → 审计层 → 回滚层

3.2 逐层拆解

L1 上下文装载层

按任务自动加载 Service Card、领域模型、接口文档、Schema、最近的 PR 与监控指标。

原则：上下文要精准、分层、可追溯。

举个具体场景：智能客服要处理“退款”，那么退款相关的业务上下文从哪来？退款政策、订单状态机、时效规则，这些必须在执行前装载进来。不是靠模型猜。

L2 工具层

代码搜索、文件编辑、测试执行、日志 / Trace 查询、数据库只读查询。工具形态可以是 MCP、RPA，也可以是普通 HTTP 接口。

三条铁律：生产默认只读、敏感表脱敏、危险命令禁止。

L3 计划层

修改前必须输出计划：改哪些文件、为什么改、预期影响是什么。

注意，这一层不是大模型的推理层，而是站在业务角度的显式声明：这次动作用到哪些资源、经过哪些环节，全部写出来。

分级策略：低风险任务自动继续，高风险任务人工审批。

L4 执行层

每次修改在独立分支、独立 Worktree、独立沙箱中完成。

底线：AI 不能污染主干环境，也不能直接修改共享开发环境。

L5 验证层

执行完成后必须跑：单测、集成测试、契约测试、静态检查、安全扫描、Schema 检查。

一句话：没有验证的 AI 修改，不进入 PR。

这里有个认知需要扭转。在传统微服务时代，测试评估是上线前的一道关卡；但到了 Agent 时代，智能体上线之后，验收才刚刚开始。你的评估集从哪来、线上怎么持续验收，这是必须提前想清楚的问题。

L6 审计层

AI 读过什么、改过什么、执行过什么命令、为什么做这个决策，全程记录。

对金融、保险、医疗这类敏感行业，这一层不是“加分项”而是“准入项”。

核心观点：无人值守不是不要责任，而是要求更强的可追溯。

L7 回滚层

AI 生成的变更必须附带回滚方案。涉及配置、数据库、消息、缓存、数据修复的，还要说明如何恢复。

延伸到 Agent 场景：你的知识库怎么回滚？本体怎么回滚？Agent 服务本身怎么回滚？这些都要有预案。

3.3 一个任务在业务 Harness 里的完整旅程

七层是静态结构，运行起来是这样一条链路：

① 任务进入 Harness
↓
② 加载 Spec(agent.md)
↓
③ 校验权限
↓
④ 加载技能(Skills)
↓
⑤ 执行工具调用
↓
⑥ 写入审计
↓
⑦ 反馈结果
↓
⑧ 触发 Hook

其中最关键的一条规则：所有副作用操作（git commit、API 写、文件写）必须经过 Hook 拦截，并记录到审计日志。

“副作用操作必须过 Hook”，这一条如果做不到，前面六层都是纸面文章。

3.4 接口契约：让业务 Harness 可被集成

业务 Harness 不应该是一堆散落的脚本，它应该是一个有契约的服务。参考设计：

POST /harness/v1/tasks
Content-Type: application/json
{
"agentId": "...",
"specRef": "spec:ORDER-2026-0825-1",
"inputs":  { ... },
"permissions": [ ... ],
"hooks": [ ... ]
}

{
"taskId": "...",
"status": "PENDING",
"traceId": "..."
}

GET /harness/v1/tasks/{taskId}/events    # SSE 流式事件

有了这套契约，业务 Harness 才能被 CI/CD、被工单系统、被上层调度平台真正集成进去。

3.5 业务 Harness 的核心原则

无人值守开发 ≠ 无限权限。

AI 必须运行在受控 Harness 里，不能依赖模型自觉，必须依赖工程化约束。

再补一句我认为最重要的：

业务 Harness 不是让 AI 更自由，而是让 AI 在正确的轨道上更高效。

越是大型后端系统，越不能依赖模型自觉。

---

四、AI 架构 Harness：从 3 层到 17 层的第一性原理推演

走到这里，你已经有了一个能跑、且跑得稳的智能体。

但它现在是个光杆司令，没有生态。

而在真实的企业级场景里，你面对的是高并发、高可用、高可靠、高准确率的要求。单个智能体撑不起这些，你需要的是架构生态。

这就是第三层：AI 架构 Harness。

4.1 用第一性原理推一遍

我们不拍脑袋，直接推演。

定律一：

Agent = LLM + Harness

定律二：

AI 应用 = 功能侧架构 + 治理侧架构

桥梁：当前 AI 应用最主要的形态，就是 Agent。所以两个等式的左边相等，右边也必然相等：

LLM + Harness = 功能侧架构 + 治理侧架构

移项，得到推论：

AI 架构 Harness = (功能侧架构 + 治理侧架构) − 模型层

这个公式的意义在于：它告诉你，除了模型层，你架构里剩下的所有东西，都是 Harness。模型是买来的、租来的、开源的；而 Harness 是你自己的核心资产。

4.2 Min：AI 应用架构的最小三层

一个 AI 应用最少需要几层？答案是3 层：

• Agent 层：决策（Decision）、执行（Execution）、交互（Interaction）
• 知识库层：私有数据（Private Data）、向量检索（Vector Search）
• 大模型层：LLM、通用能力

为什么是这三层？

• 没有 Agent 层，就没有业务编排；
• 没有大模型层，它就不是智能体，就是个普通微服务；
• 没有知识库层，它就只是个 Demo。

你去看早期的 Dify、以及后来开源的一批同类产品，骨架都是这三层：Workflow（Agent 层）+ 可插拔模型（本地部署 / Ollama / OpenAI 兼容接口）+ 可插拔向量库（Milvus / Redis Vector / PGVector）。

按公式套一下：功能侧 3 个，治理侧 0 个，减掉模型层 →此时的 AI 架构 Harness = 2 层（Agent 层 + 知识库层）。

4.3 Max：一步步推到 17 层

下面是重点。我们从这 3 层出发，每加一层都问一个“为什么必须加”。

第 1 步：加 AI 网关

企业内部不会只有一个模型。你可能同时有 DeepSeek、通义千问、Embedding 小模型、OCR 模型……

问题来了：Agent 业务逻辑层，应该感知这些下游异构模型吗？

显然不应该。所以需要一个代理层屏蔽差异，这就是 AI 网关层。它还顺带解决另一件事：某个模型挂了，Agent 应该无感，由 AI 网关做 Failover。

第 2 步：加 MCP 网关

同理，你也不会只有一个知识库。智能客服知识库、报告生成知识库、推荐知识库，再加上一堆 MCP 服务、RPA、记忆系统……

Agent 业务层同样不该感知这些异构资源。所以再加一层代理：MCP 网关层。

为什么这一层要选 MCP 协议？因为 MCP 定义的三种类型（Prompt、Tools、Resource）恰好能覆盖你所有的下游资源形态。你的知识库是 Resource，你的工具是 Tools，你的模板是 Prompt。协议天然对齐，不用自己再造一套。

第 3 步：加 Agent API 网关

你会有多个智能体：智能客服、报告生成、推荐系统……

用户只想问一句“我要退款”，他凭什么要知道该访问哪个 Agent？

所以在用户和多个智能体之间，必须加一层 Agent API 网关层，负责路由与转发。

第 4 步：加流量网关

你的存量微服务还在跑。用户下单走微服务，用户咨询走 AI 原生服务。

但对用户来说，他就是一股流量，他不该知道这个区别。

所以最外层需要一个流量网关层，统一收口，再按规则分流到微服务或 AI 原生服务。

第 5 步：加 Skills 层

能不能把关键业务流程封装成 Skill？比如“退款流程”、“售前优惠活动咨询”。

当然可以。Skill 可以放在 Agent 本地，也可以放在配置中心（如 Nacos）由客户端动态加载。

这一层的价值：把最关键、最高频的业务流程沉淀成可复用资产。

第 6 步：从单智能体到多智能体

前面的智能客服、报告生成、推荐，虽然有多个，但每一个都还是单智能体。

面对复杂任务，单智能体一定不够。所以要引入主 Agent（Master）+ 从 Agent（Slave）的多智能体结构。主 Agent 类似 ReAct 里的 Planning 角色，子 Agent 负责具体执行。

（多智能体不止主从一种，还有自由协作式、轻量 Master 式等，这里不展开。）

第 7 步：加记忆系统层

Memory 是 Agent 里极其重要的模块。

从 MCP 的视角看，Memory 属于 Resource，所以它挂在 MCP 网关后面，和知识库同级。State（状态）同理。

第 8 步：加消息队列层，从同步到异步

到这一步，问一个问题：当前这套架构是同步还是异步？

是同步的。

怎么变成异步？加 MQ。比如一个需要写数据库的请求：流量网关 → Agent API 网关 →MQ→ Agent 业务层消费处理。

至此，功能侧架构一共 11 层。

4.4 别忘了治理侧的 6 层

功能侧解决“能不能跑”，治理侧解决“敢不敢用”。这 6 层缺一不可：

层	解决什么
AI 配置中心	Prompt、模型参数、Skill 的统一配置与动态下发
AI 注册中心	Agent、工具、MCP 服务的注册与发现
AI 评估体系	评测集管理、效果验收、回归评估
AI 安全体系	安全合规、Prompt 注入防护、内容审核（金融/保险刚需）
AI 治理体系	全链路可观测：耗时、Token 消耗、成本、链路定位
AI 弹性伸缩层	应对突发流量（并发从 10 跳到 1000）的自动扩缩容

关于可观测性多说一句：AI 的可观测和传统微服务的链路追踪不是一回事。你要看的不只是耗时和错误率，还有每一步的 Token 花费、每一次调用的成本、整条推理链路到底发生了什么。定位问题的维度完全不同。

关于弹性伸缩也多说一句：AI 原生服务的典型特征是并发不高但延迟很高。这种负载特征下，突发流量的杀伤力比传统服务大得多。中午 12 点并发从 10 跳到 1000，没有弹性伸缩就是灾难。

4.5 最终答案：AI 架构 Harness = 16 层

汇总一下 17 层完整架构：

功能侧架构（11 层）

#	层
1	流量网关层
2	Agent API 网关层
3	消息队列层
4	主 Agent 业务逻辑层
5	从 Agent 业务逻辑层
6	Skills 层
7	AI 网关层
8	模型层
9	MCP 网关层
10	知识库层
11	记忆系统层

治理侧架构（6 层）

#	层
12	AI 配置中心
13	AI 注册中心
14	AI 评估体系
15	AI 安全体系
16	AI 治理体系
17	AI 弹性伸缩层

现在把公式代进去：

AI 架构 Harness = 功能侧(11) + 治理侧(6) − 模型层(1) = 16 层

除了模型层，其余 16 层全都是 Harness。

这个结论我希望你能记住。因为它意味着：在企业级 AI 应用里，你 94% 的架构工作量，都不在模型上。

顺便提一句，常有人说“这不就是网关吗”。你看，17 层里网关相关的只有 3 层，剩下 14 层跟网关没有半点关系。网关只是这套架构里很小的一块。

4.6 最关键的一条：不是层数越多越好

千万不要看完这 17 层就去堆架构。

真实情况是：你需要在 3 层和 17 层之间做选择。

• 有的开源项目，4～6 层就够用了；
• 我们自己的智能客服，选了 8 层；
• 我们的报告生成，选了 7 层。

架构能力的体现，不是你能画出 17 层，而是你知道你的场景该砍到第几层。

判断依据很简单，回到三个问题：

• 你有几个模型？这决定要不要上 AI 网关
• 你有几个智能体、几类知识源？这决定要不要上 Agent API 网关和 MCP 网关
• 你在什么行业、面对什么监管？这决定治理侧那 6 层要上几层

五、三层 Harness 的递进关系与落地路径

回到开头那张全景图，三层 Harness 是严格递进的：

技术 Harness      →  给你一个能跑的 Agent
↓
业务 Harness      →  给它装上上下文、工具、审计、回滚,让它跑得稳
↓
AI 架构 Harness   →  给它一整个生态,让它扛得住企业级的高并发与高可靠

对照到你的工作，我的建议是：

第一层（技术 Harness）：了解即可，不要自研。读懂 Codex 的分层思路，知道 Agent Loop 长什么样、外围八个模块解决什么问题就够了。这一层官方会越做越厚，你自研的投入产出比极低。

第二层（业务 Harness）：必须自研，而且要尽早。七层框架落地时，我建议按这个顺序推进，优先级从高到低：

• L4 执行层 + L2 工具层的只读约束：先把“AI 不能搞坏生产环境”这条底线守住；
• L6 审计层：出了问题能查清楚，这是所有信任的前提；
• L5 验证层：没有验证不进 PR，把质量关口卡死；
• L3 计划层 + L1 上下文层：提升准确率；
• L7 回滚层：完善兜底能力。

先守底线，再提效率。顺序反了，你会在某次事故之后被迫从头补课。

第三层（AI 架构 Harness）：按场景增量演进。从最小 3 层起步，每加一层都要能回答“为什么必须加”。加不出理由的层，就是负债。

六、写在最后

我用一句话收尾：

Harness 不是让 AI 更自由，而是让 AI 在正确的轨道上更高效。

Agent = LLM + Harness 这个公式没错，但如果你只停在这一句，它对你的落地不会产生任何帮助。

真正有价值的是：你要知道自己在建哪一层 Harness，要知道这一层有哪些工程约束是不能省的，还要知道哪些层对你的场景来说其实是过度设计。

模型的能力还会继续涨，技术 Harness 那一层会被官方一点点吞掉。但业务 Harness 和 AI 架构 Harness，永远是你自己的护城河。

因为它们装的不是通用能力，而是你的业务。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】