文章核心论点在于模型提供智能而harness智能体框架决定了你能否控制、指挥模型并在生产环境中信任它。随着模型能力的增强围绕模型的系统架构harness变得至关重要它定义了智能体的规则、边界、流程和执行策略。文章深入探讨了2026年一套成熟的harness的组成部分包括操作单元、记忆架构、工具编排、策略执行、多模型路由、持久状态管理等强调了harness在构建可靠、高效、安全的AI系统中的核心作用。核心论点模型带来智能而 harness缰绳/框架决定了你能不能控制它、指挥它并在生产环境里信任它。过去几年我们争论的几乎都是模型哪个推理更强、哪个上下文窗口更大、哪个工具调用更可靠。这些问题仍然重要。但模型越强一件事就越明显——模型更接近一台发动机而不是一辆整车。真正把这台发动机变成一支真实团队可以直接使用的东西的是它周围的那套系统——Agent harness智能体框架。本文试图把 2026 年一套成熟的 harness 逐块拆给你看。如果你想要一个能连续工作几小时、调用几十上千种能力、记得你公司是怎么运转的、能安全地触碰生产系统、扛得住上下文限制、并且稳定出现在 Slack、Teams、Web 应用或语音通话里的 AI 系统那么围绕模型的那套架构其重要性开始至少和模型本身相当。这套架构就是 harness。而在 2026 年一个正经的 harness 远不止下面这段while not done: response llm(messages, tools) execute(response.tool_calls)这就是经典的 Agent 循环把历史和所有工具都喂给模型执行它要求的一切再循环。它仍然是每个 Agent 的心脏。但一旦 Agent 进入生产这段代码里几乎每个词——messages、tools、execute、甚至while——背后都藏着一整个子系统。那个循环还在某个角落但它已经不再是架构本身。为什么现在 harness 才是有趣的部分一个好用的比喻是马和马具。一匹骏马给你原始力量马具决定这股力量能不能被控制、能不能被指向目标、能不能明天再用一次而不伤人。给马套上马具不会让它更聪明——它只是变得可用了。AI 也是一样。一个前沿模型可能完全有能力推理复杂任务但生产系统仍然要决定给模型什么上下文、它记得什么、它能发现什么、暴露哪些能力、操作怎么执行、代码跑在哪里、用哪套凭据、哪些动作需要人、失败怎么恢复、长时间工作重启后怎么活下来、结果怎么观测和评估——以及这个 Agent 到底能从哪里被找到。所有这些就是 harness。而真正让我兴奋的是harness 是我们能够把自己的要求编码进去的地方。模型带来智能harness 带来我们的规则、我们的边界、我们的流程、我们对做完了的定义。这里是工程纪律与模型能力交汇的地方。一个简化的 2026 年 harness 大致长这样这不是唯一正确的 Agent 架构——根本就没有唯一正确的架构。它只是我自己用来思考当一个 Agent 变得持久化、深度集成、对业务真的重要时会冒出哪些部件的一个心智模型。市场已经在讲同一个故事促使我现在写这篇文章的是过去几个月整个行业明显地收敛到了这个判断上。看看 Viktor——那个住在公司 Slack 或 Microsoft Teams 工作区里的 AI coworker。它在 2026 年 5 月拿了 Accel 领投的 7500 万美元 A 轮对外宣传连接了超过 3000 种工具。但它真正的赌注不是更好的模型——按他们自己的说法最终赢下战场的职场 Agent是那个几乎零安装摩擦、直接落在团队已有聊天窗口里的产品。然后就在这周的 DevDay 上OpenAI 发布了 dots带自己云电脑、跨应用记忆、有审批控制的常驻 Agent。你可以在 ChatGPT 里把一个项目交给一个 dot然后在 Slack 或 Teams 里接着聊或者直接打个语音电话——它还是同一个 Agent。OpenAI 还强调了用户自定义规则一个 dot 可以做什么、什么时候必须问人像永久删除数据这种敏感动作必须显式同意。几周前Meta 推出了 Muse——一个跑在自己虚拟机上、能在 WhatsApp 里直接被 的 Agent。用架构的眼光看这些产品你会发现它们共享同一个形状表面变来变去——Slack、Teams、WhatsApp、ChatGPT、语音但 harness 是同一套同一个身份、同一份记忆、同一套权限、同一个沙箱、同一组审批规则。Agent 之所以可移植是因为 harness 可移植。这篇文章的论点一句话模型是发动机接入渠道只是一扇门产品真正活在 harness 里。下面我们逐块拆开看。1. 别把你手里所有工具都交给模型第一个架构问题出现得非常快。想象一个企业 Agent 接了 GitHub、Jira、Slack、Google Drive、Salesforce、Stripe、AWS、Datadog、ServiceNow、Notion、PostgreSQL再加几十套内部系统。实践中这就是 100 个 MCP server每个暴露二三十个工具你很快就面对上千种可能调用。最直接的做法是一次性把所有工具都交给模型。在某些系统中这在技术上是可行的。但从架构上看这几乎总是错误的抽象。模型不应该为了弄清楚当前任务只需要哪两个功能而去阅读成千上万个功能模式。所以第一个决定是Agent 用什么单位思考。我之前写过一篇文章主张 Agent 应该用 operation操作思考——像列出我们用了哪些 AWS 服务、“算一下这个月按团队拆分的云成本”、建一个跟进任务这样的意图单元——而不是用原始命令或 UI 点击来思考。弱工具层只是镜像应用界面click_customer_tab()、press_export()好的工具层表达的是有意义的工作。这里我再推一步因为这才是渐进式披露能成立的基础。Operation 是一个意图单元。它怎么实现是另一个问题。而实现方式其实只有三种。我们在用哪些 AWS 服务是一个 operation它恰好由对 AWS MCP server 的一次工具调用实现没人需要为它写什么流程——它就是现成的也应该是现成的。按我们的标准格式算一下这个月按团队拆分的云成本也是一个 operation但它跨好几个工具并且对答案长什么样有规则。第二种 operation 有两种打包方式。作为复合工具composite tool组合逻辑写在 MCP server 里Agent 一次调用结果是确定性的策略层看到的是一个连贯动作。作为技能skill组合逻辑写成指令——按这个顺序用这些工具、这样聚合、返回这种格式——模型自己照着做可能是多次调用也可能直接写代码。意图是同一个打包方式决定了保证级别。实践中operation 通常先以 skill 形式诞生等它稳定下来、变得关键之后再被编译成复合工具。那 capability能力在哪里Capability 是分组——像aws、github、jira这样的一个集成或 MCP server。它是你去连接、认证、施加策略的单位。对 Agent 来说它主要是 operation 的元数据是一个可以用来过滤的维度而不是必须逐级下钻的层级。Capability → 把工具分组 (aws, github, jira) Tool → 带 schema 的原子动作 Skill → 引用工具说明怎么组合它们 Operation → Agent 搜索并执行的东西 由上面任意一种来实现这样一来发现discovery就变成一条渐进路径而不是几个并列目录。实际让这套东西跑起来有两个关键细节。第一schema 只存在一个地方——MCP 工具定义里。skill 不复制输入输出 schema它用 id 引用工具skill 被加载时harness 解析这些引用把相关 schema 放进上下文。第二简单路径保持简单。对于我们在用哪些 AWS 服务搜索只返回一个工具模型加载它的 schema 然后调用。直接工具调用、不经过任何 skill是一条一等公民路径不是例外。另外list_capabilities()也有存在的理由。用户经常不知道 Agent 接了什么所以你能访问什么“是一个真实问题。当两个接入系统都可能匹配同一个请求——比如建个任务”Jira 和 Linear 都行——Agent 应该能看到这种二义性并主动问而不是瞎猜。MCP 是这一切的传输层和契约。harness 决定 operation 怎么被发现、组合、授权和执行。2. 知识也要渐进加载把是什么和怎么做分开其他部分的 harness 也清楚了。我反复回到这个拆分Memory → 我们知道什么 Skills → 我们怎么做 Capabilities → 我们能触达哪些系统 Tools → 具体能执行什么 Operations → Agent 实际在请求什么这些概念相关但不能互换。很多混乱的 Agent 架构都是因为把它们混在了一起——通常是把流程塞进工具描述里或者把工具 schema 塞进流程里。Skill 值得再多说两句因为它会悄悄长大。一个成熟的 Agent 最终会积累几百条流程事件响应、发布管理、客户上手、安全评审、迁移规划、一个走查边界/信任区/数据流/故障域的架构评审。这些都不是 API它们是程序性知识——那种高级工程师脑子里装着、初级工程师要学好几个月才能学会的东西。把每一条都注入每一次 prompt我们就把刚才给工具解决的问题又复刻了一遍。模式是一样的模型只看到紧凑的元数据一个名字、一行描述完整流程只在任务需要它时才进入工作上下文。如果你只有几十个 skill把它们的名字和描述都留在 system prompt 里完全 OK工具则有几千个、还在不断变应该留在搜索后面。渐进式披露既适用于能力也适用于知识。3. 记忆需要自己的架构记忆是实现层面最容易做得过于原始的地方。常见做法是把对话总结一下、存起来、永远注入。小系统能用但 scale 不上去。更好的架构至少分三层工作上下文现在窗口里有什么、持久记忆因为以后可能有用所以留下来的东西、以及记忆检索在正确的时机把正确的片段捞回来。对话本身不是记忆。记忆是值得保留的那部分残渣。检索应该是混合式的。在主模型调用之前harness 可以自动把相关的项目偏好、过去的架构决策、组织约束拉进初始上下文。但自动检索不可能猜到一切所以模型也应该有一个显式的search_memory(query)原语留给任务进行到一半、它意识到我还缺东西的时刻——比如这个团队生产部署的命名规范是什么用户请求 ↓ 自动记忆检索 ──► 初始上下文 ↓ Agent 开始干活 ↓ 我需要更多上下文 ↓ search_memory(...) ──► 追加记忆记忆整理应该是独立的流水线。如果用户说我们架构图不用 PlantUML 了以后用 Mermaid把整段对话永远存下来毫无意义。你要的是一条规范化的事实*架构图用 Mermaid不用 PlantUML。*做到这一步需要抽取、相关性打分、规范化、去重、合并——这些都不需要在热路径上跑。它可以在这一轮结束后异步做主循环不用在每条消息之后都停下来决定记忆未来该长什么样。记忆需要 scope。一旦企业记忆变成全局无差别就危险了。用户记忆个人偏好、工作习惯、工作区记忆团队约定、架构决策、owner、任务/项目记忆当前目标、中间发现、未决问题、技能知识流程、事件、已知的集成坑——是不同的东西有不同的 owner 和生命周期。一个用户偏好绝不应该悄悄变成组织策略在某个项目里做的决定也不应该悄悄变成全公司规则。记忆需要 scope、provenance、ownership、lifecycle。向量相似度本身不是记忆架构。4. 检索只是上下文选择的一半这里有一个更微妙的问题我觉得值得更多关注。假设记忆搜索返回 40 条候选operation 搜索找到 25 个语义接近任务的工具和 12 个 skill。检索回答了什么可能相关。它没有回答Agent 实际应该收到什么。传统上团队用 embedding、启发式、cross-encoder、reranker、再一次 LLM 调用、或者混合来解决。2026 年这个位置还有一个有意思的选项像 TypeSafe AI 的 Jev 这种面向决策的模型。Jev 不打算做又一个对话式 LLM。TypeSafe 把它描述成System One模型做快速、结构化的决策你给它上下文和一个答案空间受限的问题它返回类别、分数和概率而不是生成文本。形状上你会觉得像带分类头的 BERT——区别是问题和标签是请求时定义的不用为每个决策单独训一个分类器。这个形状刚好对上一整族 harness 工作负载检索回来的记忆 → 选择 / 重排 → 真正注入的记忆 候选 operation → 选择 / 打分 → 值得加载的 operation 进来的请求 → 分类 → 路由 / 选模型 / 策略信号我得说清楚因为这很重要我不是在给 Jev 打广告也不是说每个 harness 都该用它。早期公开测试结果令人鼓舞但好坏参半。Parallel 的评测发现它在某些场景打平或超过他们自己训练的模型但在标签集很大时吃力至少有一份公开现场报告显示一个 Jev 配置没跑赢它自己的向量基线。对你的场景确定性规则可能更好专用分类器、cross-encoder、纯 embedding 相似度、小 LLM 也可能更好。任何专用模型都必须在你自己的数据上评测。架构层面的教训比某一个模型更广选择不一定需要生成。一个前沿推理模型不该因为它能做就自动成为所有内部决策的分类器、路由器、reranker、相关性法官和策略打分器。harness 应该在主模型看到东西之前先把决策空间缩小一个 harness 每时每刻都在做几十个这种小决定该搜哪个记忆命名空间哪个 capability 相关该加载哪个 operation检索回来的候选里哪些值得进上下文这个请求到底需不需要大模型这些都是分类、路由、排序、选择问题——不是写作问题。正确的问题不是我们要不要加 Jev而是这是一个生成问题还是一个受约束的选择问题答对了省上下文、省延迟、省钱让昂贵的推理模型把预算花在真正需要推理的地方。5. 代码执行改变了工具编排方式经典 Agent 循环是模型和工具调用之间反复横跳。几步还好。但想象一下跨三个系统处理 500 条记录。让模型编排每一次单独调用慢、贵、脆。一旦 Agent 理解了任务和可用的 operation它就可以直接写一段程序customers crm.search_customers(statusactive) results [] for customer in customers: invoices billing.list_invoices(customer_idcustomer.id) overdue [i for i in invoices if i.status overdue] if overdue: results.append({customer: customer, invoices: overdue})流程变成模型生成执行逻辑沙箱用程序化工具调用跑它runtime 聚合和转换只把结果回给模型。LLM 推理工作流runtime 处理重复机械动作。我想强调的是后果一旦代码执行成为中心沙箱就成了 Agent 的一部分。它不再是钉在旁边的计算器——它是 Agent 的工作电脑有文件系统、shell、Python runtime、临时数据库、Git checkout、下载的文件、生成的产物和工具代理。OpenAI dots、Meta Muse、以及绝大多数正经编码 Agent 现在都给每个 Agent 一台自己的云机器这不是巧合。这和一个 LLM 坐在 REST 端点后面是完全不同的架构。6. API 优先浏览器兜底Computer use 很强大很容易让人想把它当万能适配器。但它不该自动替代 API。如果一个 Agent 用一次确定性 API 调用就能拿到发票让它点过六个浏览器页面就是更差的抽象——更慢、更脆、更难审计。一个合理的能力层级长这样结构化 API / MCP → 首选 代码执行 → 组合和转换 浏览器 / computer use → 兜底或只在系统只有 UI 时用浏览器在这些时候才值得出场没有 API、API 不全、遗留系统只暴露 UI、需要从渲染后的界面取证、或者工作流本身就是一个 UI 工作流。它扩展能力边界——但不该抹掉好的软件接口。7. 凭据永远不进模型上下文策略坐在意图和执行之间如果一个 Agent 能操作很多系统凭据架构就变得关键。反模式是把STRIPE_API_KEY、GITHUB_TOKEN这些东西放到模型上下文附近任何地方。正确模式是一条模型只表达意图的路径模型应该知道我被允许读发票。它永远不需要知道这是 OAuth refresh token。Capability 和 credential 是两回事——让它们一直是两回事。同一个网关也是策略住的地方。Agent 决定做一件事不代表它就应该发生。search_customer()和refund_customer($18,000)可能都是合法工具但显然不该共享同一种执行语义。策略层按风险给 operation 分级READ → 直接执行 LOW-RISK WRITE → 执行 审计 SENSITIVE WRITE → 要确认 DESTRUCTIVE / HIGH IMPACT → 必须显式批准所以真正的执行路径不是模型调用工具而是意图 → operation → 策略引擎 → 权限检查 → 风险评估 → 执行或者等人。这正是 OpenAI 给 dots 选的形状——用户自定义规则、敏感动作必须同意——我也期望任何生产 harness 都长这样。8. Human-in-the-loop 是协议的一部分不是 UI 的补丁想象 Agent 正在准备一次生产部署服务payments-api版本 4.7.2要替换三个 pod。弱版本是模型在聊天框里打你要我继续吗然后祈祷自己能正确解析回答。好版本是 harness 发出一个结构化的 pending action。表面层把它渲染成真正的控件——批准 / 拒绝——这个决定恢复被暂停的执行状态。Human-in-the-loop 不再是 UI 事后补的东西它成了执行生命周期的一部分。界面不再只是渲染 Markdown它在参与协议。这正是 MCP elicitation 和 MCP Apps 要解决的问题。这里有一个区别非常重要。审批永远不应该依赖模型选择去问。当一个有风险的execute_operation撞到策略引擎harness 自己就返回 pending 状态、暂停执行——不管模型本来想干嘛。模型得到的是另一个原语ask_human()留给它自己缺东西的时候要报哪个月两个接了的任务系统用哪个支付服务指的是 staging 还是 production在短同步聊天里这就是一句回复在长后台任务里这是命根子——任务带着完整状态暂停问题到达正确的表面Slack 里的按钮、Teams 里的卡片答案在它停下的地方精确恢复工作。模型主动澄清和策略强制审批在屏幕上看起来相似但属于不同层。9. 模型路由也归 harness 管“不是每个决策都需要前沿模型这条原则对主模型本身也适用。一个 harness 可以根据复杂度、风险、延迟、成本和任务类型在快模型、均衡模型、前沿推理模型、编码模型、视觉模型或专用分类器之间选。不再是所有东西 → 最大模型”而是任务 → 分类 → 需要什么能力 → 选模型 → 执行。很多应用不需要动态路由那也完全 OK。但一旦一个 Agent 跑几千、几百万个任务模型选择就从一个配置开关变成了架构问题——它自然复用第 4 节里那套选择层。10. Agent 不该属于 Slack这是市场现在喊得最响的模式值得认真对待。很多 Agent 一开始是一个 Slack bot。然后有人问能不能放到 Teams 里——突然半个代码库要重写。这是通信表面和 Agent 运行时耦合太紧最明显的信号。更好的架构是把每个渠道都当成同一个 runtime 上面的 adapter实践中这意味着把渠道特有的事件——Slack 事件、Teams activity、WhatsApp 消息、语音转写、API 请求——归一化成同一种内部表示{ actor: ..., workspace: ..., conversation: ..., message: ..., attachments: [], surface: slack, permissions: [] }harness 永远只操作这种归一化事件。出去的时候表面适配器把 Agent 的响应翻译成该渠道支持的形式Slack block、Teams adaptive card、Web component、或者一段语音回复。连第 8 节那个 pending action 审批都变成 Slack 里的一个按钮、Teams 里的一张卡片、语音里的一句说好的就确认——同一个动作、同一份状态不同渲染。这正是 Viktor、dots、Muse 这类产品能在用户已经在的地方接住他们的原因。Agent 在表面之间移动但不动脑子。真正值钱的资产从来不是那个 Slack bot而是那个持久化的 Agent 身份和它背后的 harness。11. 长任务 Agent 需要持久状态一旦一个 Agent 能工作几分钟、几小时、几天另一个假设就破了*一个 HTTP 请求 一个 Agent 任务。*长时间工作需要持久的执行状态——目标、当前计划、已完成步骤、产物、待办操作、审批、失败和检查点——以及在这些状态之间迁移而不丢东西的能力running → waiting for API → waiting for human → resumed → completed。到那一步它开始看起来不太像聊天机器人基础设施而更像一个工作流 runtime。这不是偶然。现代 Agent 正在变成控制回路里嵌着一个 LLM 的有状态分布式系统。最新 MCP 规范里的后台任务和多轮请求就是协议在追这个现实。12. 可观测性抓轨迹eval 测整个系统传统监控问的是请求成功了吗、花了多久、有没有 500。Agent 监控需要多得多。Agent 当时认为任务是什么拉了哪些记忆加载了哪个 skill、选了哪个 capability、尝试了哪些 operation触发了什么策略决定、请求了哪些审批、跑了什么代码、什么失败了、怎么恢复的整个东西花了多少钱结果真的达成目标了吗可观测性的单位不再是 request而是轨迹trajectory。没有它调试 Agent 行为就是猜。这直接通向 eval。harness 本身就会制造行为。改一下记忆检索、工具描述、skill 指令、路由、压缩或审批规则即使模型一个字节都不变结果也会变。所以 eval 必须测系统不只是模型Model Context Memory Skills Tools Policies Execution Agent 行为值得跟踪的指标包括任务成功率、工具选择准确率、多余的工具调用、策略违反、恢复成功率、延迟、token 消耗、每个成功任务的成本、人工介入率、记忆检索质量。轨迹喂给可观测性可观测性喂给 evaleval 喂给 harness 改进。真正的质量提升大多来自这个循环。把所有部件拼起来这是把每块都装回去之后更完整的心智模型。重要的是模型坐在架构里面。架构不坐在模型里面。当一切都被正确拆开一件好事会发生——模型面对的接口变得惊人地小search_memory(query) list_capabilities() search_operations(query, capability?) load_operation(id) execute_operation(id, args) run_code(code) delegate_task(task) ask_human(question, options?)其中三个负责发现的重活list_capabilities告诉它接了哪些系统search_operations跨工具、复合工具和 skill 找到合适的工作单元load_operation只把需要的 schema 或指令带进来——不多不少。注意批准是故意不在这个列表里的它不是模型调用的东西而是 harness 强制的东西。在这几个原语背后可能藏着几百个 skill、跨几十台 MCP server 的几千个工具、几百万条记忆、多模型、MCP server、浏览器、数据库和云环境。复杂度没有消失——它只是住在渐进可发现的抽象后面而不是每次模型调用里。对我来说这比再往 prompt 里加一个工具是有意思得多的扩展 Agent 的方式。Harness 正在变成产品本身AI 工程以前长这样应用 LLM API。然后变成应用 LLM RAG 工具。现在它在走向一个 harness——上下文管理、记忆、带渐进发现的 operation 目录、选择、工具执行、代码 runtime、浏览器、模型路由、策略、身份、凭据、人工审批、持久状态、可观测性和 eval——模型插在正中间。模型仍然极其重要。但把一个强模型换成另一个正变得比重建它周围的一切更容易。周围那套系统装着你的运营知识、权限、记忆、集成、工作流、安全边界、评估框架、用户体验和 Agent 身份。换句话说harness 越来越就是产品本身表面只是产品今天恰好被触达的那扇门。这不是一张蓝图这一切不意味着每个 AI 应用都该把上面全实现一遍。请不要。如果你的应用只需要 5 个工具、处理短同步任务直接给模型 5 个工具可能就是正确设计。如果你没有持久的用户上下文你不需要一套精巧的记忆系统。如果简单向量检索已经给你很好的上下文reranker 或决策模型可能只加延迟和运维开销。如果你的工作流从不碰有后果的动作精巧的审批引擎是多余的。如果一个模型已经可靠地处理你的负载动态路由就是复杂度。架构应该追随约束而不是追随潮流。我也想诚实说明范围。我描述的是一个高层、相当精简的 setup——是我认为可以公开讨论的那部分。每个正经产品都在上面堆了更多自己的排序技巧、记忆启发式、评估数据集、安全层和编排细节。那通常才是每个团队真正的竞争优势所在也理应保密。但骨架——当一个 Agent 变得持久、集成、多表面、长时间运行、在业务上重要时会开始出现的那些部件——已经足够共通值得一起讨论。有些系统只需要其中 20%有些会需要多得多。真正的转变Agent 工程里有意思的转变不是更好的模型而是围绕模型的更好的系统。我们在从我该给模型哪些工具“走向operation 该怎么被发现”从我能塞多少对话历史“走向什么东西值得变成记忆”从我怎么检索相关上下文“走向我怎么检索、排序、选择并只注入值得为之付费的上下文”从我怎么写 system prompt“走向这个任务该加载哪些知识”从我怎么调三个工具“走向模型到底该不该亲自编排这些调用还是该直接写一段程序”从Agent 能不能执行这个动作“走向它被授权了吗、以谁的身份、用哪份凭据、需不需要人批准”。以及从我们做了一个 Slack bot走向我们做了一个 Agent它恰好能通过 Slack 被触达。最后这条可能是所有转变里最重要的。最后一句话一匹骏马没有好的马具就像一个强大的模型没有好的 harness。它可能很快。它可能很聪明。它甚至可能给你惊喜。但生产系统不是围绕惊喜建的——它们是围绕可控的能力建的。现代 harness 就是那台把模型智能变成持久、可发现、可执行、可观测、可移植、可治理之物的机器。模型负责推理。记忆保存知识。operation 定义 Agent 能做什么skill 保存怎么把它做好。Capability 连接真实系统。选择器在昂贵推理之前切掉噪音。沙箱给 Agent 一个干活的地方。策略划边界审批让人保持控制表面只是人走过的门。harness 把这一切连起来。所以下次评估你的 Agent 架构时别只问模型多聪明。问问你在这份智能周围建了一套什么样的系统。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。