h5响应式网站技术做网站可以做什么

h5响应式网站技术,做网站可以做什么,wordpress帮助中心模板,国外引流推广平台前言 大家好#xff0c;我是星仔。 随着 2025 年即将画上句号#xff0c;我想对”Agent 元年“根据个人这一年的实践和认知进行一次收敛。 技术观点#xff1a;Agent 架构之争已定#xff0c;收敛至以 Claude Code 和 Deep Agent 为代表的「通用型 Agent」形态。 Claud…前言大家好我是星仔。随着 2025 年即将画上句号我想对”Agent 元年“根据个人这一年的实践和认知进行一次收敛。技术观点Agent 架构之争已定收敛至以 Claude Code 和 Deep Agent 为代表的「通用型 Agent」形态。Claude Code 虽然在 2025 年 3 月作为“智能终端编程助手”推出但其不止于编程。社区里“不务正业”的玩法社区的开发者迅速挖掘了它的潜力将其用于整理知识库、辅助博客创作、项目管理案例Claude Code 「全球“薅羊毛”第一人」刘小排曾用 200 美元套餐消耗 5 万美元 Token曾断言“只要有 SOP就没有 Claude Code 执行不了的任务。”官方的战略转向Anthropic 官方也注意到这种转变2025 年 9 月官方发布博文《Building agents with the Claude Agent SDK》[1]正式将 “Claude Code SDK” 更名为 “Claude Agent SDK”。背后的逻辑Anthropic 意识到 Claude Code 核心的 Plan规划能力、上下文自动压缩、文件系统访问 等机制不仅适用于编程同样完美适配深度研究、视频制作等非编程任务。因此赶紧改名防止大家从命名上认为它们只能做代码。不是计划出来的是演化出来的也许 Anthropic 一开始也不知道 claude code 能做这么多事情随着社区里更多更多的玩法才逐渐清晰。这也引出了一个关键问题它的核心架构究竟有何特点我们又该如何对其进行修改适配将其从“通用型”转化为特定领域的“垂类 Agent”将在后文详细展开。行业认知: 2025 年作为 Agent 元年既没有悲观者眼中的“名不副实”也未完全达到乐观者预期的“全面替代”而是处于稳步落地的中间态。作为一线从业者我的评价是技术已就绪爆发在局部。验证过的成功 Deep Research 和 Claude Code 已经完全融入日常工作流成为了稳定可靠的生产力工具。看不见的繁荣 在招聘、市场营销、医疗等垂直领域许多 Agent 产品早已实现百万美元营收。但由于大量业务集中在出海方向导致国内体感不强。核心瓶颈的变化 年中时我们还在纠结技术架构但现在架构已趋于统一。当前的真正挑战在于“业务重塑”——即依然需要懂技术的一线从业者将传统 SOP标准作业程序解构和把行业知识提炼出来以 Agent 友好的方式沉淀为新的工作流。基于以上背景本文将从 Deep Agent 为切入点分享我作为一线开发者在 2025 年的实战感悟。主要参考资料 Anthropic[2]、LangGraph[3]、Manus[4]、Philipp[5]。关于参考资料的说明在 Agent 领域这些一线头部企业特别是 Anthropic对技术落地和架构的理解属于 T0 版本其认知深度和实效性目前远超学术论文。如果你想真正研究 Agent建议暂时放下学术论文直接关注一线企业的落地实践和思考。一、先来下个定义什么是”Deep Agent“ 首先它是“Deep”的个人认为有两点需要做到特征一够“垂”行业性具体示例如下1.招聘 Agent 示例输入 一位 AI 芯片架构师的姓名。任务 一份专业背景报告。衡量标准如何才算“够垂”报告内容研究方向、核心项目、融资历史等逻辑严谨、信息全面、专业性强无任何重要信息遗漏和事实错误达到高级招聘经理的水准。观感上让老板无法分辨是人工还是 AI 生成。2.市场营销 Agent 示例输入某品牌的产品信息和市场定位。任务筛选符合品牌调性的网红KOL/KOC并给出市场报价。衡量标准如何才算“够垂”最终筛选出的名单和报价与公司市场部人工筛选的结果高度重合例如 70% 以上重合且报价在人工测算的合理区间内。这些就是你的 agent 够“垂”的表现。假如你的 Agent 输出与通用型工具如 Manus一样那就是不合格的。行业性指的是什么呢所谓的行业性是指 Agent 的知识和能力必须源于该行业的深度实践和共识包括但不限于业务定义的理想态如高级招聘专家定义的标准流程、评分标准或成功方法论。过往案例积累 行业内成功的或失败的关键案例如一次成功的招聘、一次失败的市场活动。行业潜规则/默契 仅在特定圈子如猎头行业流传的专业共识、价格默契、资源倾向或风险偏好。特征二Long-running稳定性2025 年 2 月 24 日Claude 3.7 Sonnet 发布。Anthropic 为了证明 claude 3.7 Sonnet 能在在复杂任务中的规划和长期连贯性。在 Twitch 平台上开启了 “Claude Plays Pokemon” 的直播让 claude 自己连续玩好几个小时的宠物小精灵。Claude Plays 宠物小精灵[6]2025 年 11 月 18 日Gemini3 发布Blog 里提到 Plan anything[7]。Gemini 3 提升了其跨越长周期可靠规划的能力。例如用户要求规划并预订下月初1 月 6 日、7 日从兰州到法兰克福的往返行程和酒店。规划流程涉及多步骤的操作如检查 Google 日历确保出发时间不与标记为“重要”的会议冲突。如果发现冲突自动将会议重新安排到会议周内最接近的空闲时间。在 Google Keep 中创建包含法兰克福一月平均气温信息的打包清单。 这个例子展示了 Agent 必须具备跨应用、多步骤、具有决策和修正能力的长时间任务执行能力。发送行程安排到你的 Google email。2025 年 12 月 1 日豆包手机发布。Agent 能够通过感受图形界面和仿人化的操作例如点击屏幕完成一系列任务。例如“帮我查一下从 [城市 A] 到 [城市 B] 最便宜的机票然后预订下来并给我订一个 [城市 B] 附近评价最好的酒店。”以上案例共同证明一个 Deep 的 Agent 必须能够实现 “Long Time Run”这涵盖了两个关键维度1.Agent 必须能够长时间持续运行而不崩溃例如连续玩 24 小时宠物小精灵直至通关确保任务不会因系统不稳定而中断。2.Agent 必须能连续、保质保量地执行多步骤任务涉及到大量调用工具Tools和外部服务APIs。例如相比于简单的“发微信告诉妈妈今晚我晚点回家”更复杂的任务是“找一款 500 元的大品牌秋冬大衣并在京东、淘宝、拼多多比较综合所有评论找到推荐的 3 件并发到我邮箱”。后一任务可能涉及多达 50 个 tool 或 API 的连续调用。其次它是“Agent”Deep Agent它是一个 Agent。以下相信已经是公认的对 Agent 的定义An LLM agent runs tools in a loop to achieve a goal.这是一个老生常谈的故事。Workflow 胜在稳定Agent 胜在上限高。传统做业务开发的同事往往追求稳定包括我自己。但最近本人又有一些新的思考“We are managing risk, not eliminating variance”。甚至有人戏称拉投资用 Agent 讲故事做业务踏踏实实用 Workflow 。这句玩笑背后折射出现实的考量Workflow 胜在确定性而 Agent 胜在上限。投资人或许能容忍 Agent 偶尔的“幻觉”甚至将其视为智能的体现但业务交付更看重从 A 到 B 的稳定达标。如果用一句话概括二者的本质区别我认为是复杂度的转移Workflow 将错综复杂的业务逻辑显式地构建为“有向图”而 Agent 则将这些逻辑抽象为自然语言。在我们将架构简化为“Prompt Tool”的同时并没有消除复杂度仅仅是将复杂度从“流程编排”转移到了“Prompt 设计”之中。但跳出形态之争无论你选择 Workflow 还是 Agent核心逻辑是一致的我们都在实践 Test-Time Scaling Law。 即通过良好的上下文工程Context Engineering让模型“合理”地消耗更多 Token以换取解决更难题目的能力或更高的任务准确率。我们可以设想一场算法比赛给定一个复杂的业务场景、5 个不同模型厂商的 api、 单次 20 万 Token 的消耗上限比拼业务准确率。我相信 100 个开发者会给出 100 种方案有人会构建不同的 Workflow有人会打磨 Agent 的 抽象实现的路径本身就是充满了多样性。本文重点还是讲 Agent但在后续的实践部分会演示如何将一个 Workflow 变成 Agent。二、围绕上述特点如何构建 Deep Agent维度一把业务知识丝滑地融入到 Agent目前的常见做法1.融入 Prompt绞尽脑汁地编写 prompt试图把业务逻辑“翻译”成模型能懂的口吻。这种方式往往僵化且死板难以灵活应对复杂场景。2.企业知识库 (RAG)虽然能解决知识体量问题。但需要定义 Index、处理向量化、精心切分文档……整个过程笨重。这些做法都不够“丝滑”。直到 Anthropic 在 2025 年 10 月提出了 Agent Skills我看到了一种优雅的解法。Blog: 《Equipping agents for the real world with Agent Skills》https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skillsYoutube: 《Don’t Build Agents, Build Skills Instead – Barry Zhang Mahesh Murag, Anthropic》https://www.youtube.com/aiDotEngineerSkill 本质上是一个多层级的文件系统。这个文件系统里封装了指令、脚本和相关资源旨在让 Agent 可以动态地发现和加载这些内容以便更好地执行特定任务。技能通过将您的专业知识打包成可组合的资源提供给 Claude从而扩展了 Claude 的能力将通用代理转化为适合您需求的专业化代理。用官网 Blog 的例子来说明例子Claude 对理解 PDF 已经很强了但在直接操作它们例如填写表格的能力上受到限制。因此Claude 抽象出一个 pdf 的 skill。最简单地说技能是一个包含 SKILL.md 文件的目录。该文件必须以 YAML Frontmatter 开头其中包含一些必需的元数据name 和 description。在启动时代理会将所有已安装技能的 name 和 description预加载到其系统提示中。这些元数据是渐进式披露progressive disclosure的第一级它提供了刚好足够的信息让 Claude 知道何时应该使用每个技能而无需将所有内容都加载到上下文context中。该文件实际的正文是第二级细节。如果 Claude 认为该技能与当前任务相关它将通过读取完整的 SKILL.md 文件到上下文context中来加载该技能。一个 SKILL.md 文件必须以包含文件名和描述的 YAML Frontmatter 开头这些内容会在启动时加载到其系统提示中。随着技能复杂性的增加它们可能包含太多上下文而无法放入单个 SKILL.md 中或者包含仅在特定场景下才相关的上下文。在这些情况下技能可以在其目录内捆绑额外的文件并从 SKILL.md 中按名称引用它们。这些额外的链接文件是第三级及更深层次的细节Claude 可以选择仅在需要时导航和发现它们。在下面所示的 PDF 技能中SKILL.md 引用了两个额外的文件reference.md 和 forms.md技能作者选择将它们与核心的 SKILL.md 捆绑在一起。通过将填写表格的指令移动到一个单独的文件forms.md中技能作者能够保持核心技能的精简相信 Claude 只有在填写表格时才会读取 forms.md。渐进式披露是使 Agent Skills 灵活和可扩展的核心设计原则。就像一本组织良好的手册从目录开始接着是特定的章节最后是详细的附录技能允许 Claude 仅在需要时加载信息技能元数据name 和 description→ 预加载到系统提示 (System Prompt) 中。SKILL.md 的全部内容 → 仅在相关时加载到上下文context中。附加文件 (如 forms.md) → 仅在需要时被发现和加载到上下文context中。以下图表展示了当用户消息触发技能时上下文窗口是如何变化的。技能通过您的系统提示在上下文窗口中被触发。所示的操作序列1.开始时上下文窗口包含核心系统提示和所有已安装技能的元数据以及用户的初始消息2.Claude 通过调用 Bash 工具来读取 pdf/SKILL.md 的内容从而触发 PDF 技能3.Claude 选择读取技能中捆绑的 forms.md 文件4.最后Claude 在加载了 PDF 技能中的相关指令后继续执行用户任务。Skills 还可以包含代码官网示例中PDF 技能包含一个预先编写的 Python 脚本该脚本可以读取 PDF 并提取所有表单字段。Claude 可以运行此脚本而无需将脚本或 PDF 加载到上下文环境中。而且由于代码具有确定性因此这个工作流程是一致且可重复的。从这个角度来看skills 多多少少还有取代 tools 或 mcp 的作用。假如你的场景因为外部编写的 mcp 字段定义得不好其实你可以是可以把它变成 skills写一些 case来提升提升调用的准确率的这样子从外部的不可控变成自己掌控。为什么好1.渐进式披露和加载带来更好的 Context 管理彻底告别把所有背景信息一次性塞进 Prompt 的暴力做法。通过分级加载大模型变得更轻快、更专注。2.能让工程师进入“业务心流”状态这种文件结构迫使工程师必须梳理清楚业务逻辑。编写 Skill 的过程本质上就是对业务进行高内聚、低耦合的抽象过程。这感觉是 AI 时代更好的人机协作方式人来做高层的业务抽象AI 来完成具体的事情。3.高度可复用Skill 是独立的文件夹。同事想了解和复用你的业务逻辑直接把文件夹 Copy 给他即可觉得好用的直接加入到自己的 skills 就好了。4.部分代码更稳定想想调用代码更加稳定假如我们是用 mcp_hub tools 时假如有 50 个 tools都需加载到 system prompt但假如用 Agents skills它是按需加载的。同 1但更针对工具和代码调用。有一大堆开源的 skill 可以参考。HTTPS://GitHub.com/anthropics/skills/tree/main/skills不过思想虽美落地时仍需“祛魅”。在实际工程中你会发现一个残酷的现实Claude 模型能以 98% 的概率稳定触发和调用这些 Skills非 Claude 模型如豆包、DeepSeek 等触发成功率可能仅维持在 80% 左右甚至更低无论如何 Claude Skill 是 2025 年 AI 应用我认为的最佳工作。如此简单而美的工作用最直观、清晰、简练的方式解决了 Agent 复杂能力的封装与扩展问题。维度二怎么 Long-Runninglanggraph 提出来 4 种方法让你的 agent 在长时间运行不崩溃甚至 langgraph 开发了一个包就叫 Deep Agent[8]。里面提到了 4 种方法。Planning规划是深度代理能够在其目标上执行更长时间跨度任务的重要组成部分。•任务分解 规划工具例如内置的 write_todos 工具使得代理可以将复杂的任务分解为离散的步骤跟踪进度并根据新信息调整计划。•保持焦点 规划工具通过在模型的上下文context中创建待办事项列表等消息帮助代理在执行过程中保持正确的轨道。Sub-Agents子代理的目的是允许代理将任务拆分并实现上下文隔离。上下文隔离: 子任务的执行过程不会污染主智能体的上下文。并行执行: 多个子任务可以同时进行大幅提升效率。专业化分工: 可以为不同的子智能体配置专属的工具和指令。Token 效率: 子智能体完成任务后只将最终的、高度综合的结果返回给主智能体极大地压缩了上下文。但 Sub-Agents 的架构已经收敛到一个超强的 main-agent必要时再按需调用 sub agent 的架构。例如下图的 supervisor。这种架构还有个好处KV cache 能很好地利用上省钱跑得快。File System•上下文卸载 文件系统如 ls、read_file、write_file、edit_file 等工具允许代理将大量的上下文卸载到文件中。这有助于防止上下文窗口溢出并避免由于上下文过多导致的大语言模型性能下降。•共享工作区 文件系统可用作所有代理包括子代理协作的共享工作区。•长期记忆 代理可以通过文件系统存储然后稍后读取笔记或信息充当“记忆”功能。此外文件系统也可以用于存储代理可执行的脚本或“技能”并通过命令行工具如 Bash 工具调用。SyStem Prompt系统提示在深度代理的实现中至关重要。最优秀的 code cli 或 deep research 往往拥有非常复杂和详细的系统提示。例如 claude deep research 的 prompt。•详细指导 系统提示通常很长包含关于如何使用各种工具的详细说明。•示例学习 它们可能包含少量示例few-shot prompts指导代理在特定情况下如何行动。•复杂性承载 尽管模型能力强大但依然需要提供数百甚至数千行的详细指令这是因为提示工程仍然非常重要。通过细致的提示可以将应用的复杂性转移到提示本身。这些详细指令通常会定义1.何时应该暂停执行并进行规划的识别标准。2.何时应该生成子智能体以及何时应该自己完成工作的决策协议。3.所有可用工具的详细定义、使用方法和最佳实践示例。4.文件命名和目录结构的标准规范以保证工作空间的整洁。这四大支柱并非孤立存在它们相辅相成共同构成了 Deep Agent 的核心运作机制。而将这一切串联起来的底层技术正是“上下文工程”。三、Agent 技术形态的收敛在 10 月份前我觉得 Agent 的技术发展还没收敛的。证据一自 Manus 于三月份推出到十月份他们已经重构了 Manus 的架构五次[9]。证据二LangChain 在 2025 年 10 月 才正式上线 1.0 正式版本v1.0并同时推出了 DeepAgent[10]。但 2025 年 10 月份后我认为已经收敛收敛到以 Claude Agent SDK[11] 和 Deep Agent[12] 为代表的架构。这种架构有什么特点呢上面已经介绍了一部分它是Main Agent - Sub Agent主从架构还具备自主规划Planning能力和独立的文件系统概念。还有些没提到包括上下文自动压缩 (Context Compression)当 Token 使用量达到上限如 200k的 80% 时自动调用总结模型对前文进行摘要压缩释放空间。分层的工具调用解决上下文拥挤的问题向 LLM 一次性灌输超过 100 个工具会导致上下文混淆(Context Confusion)极易引发幻觉或参数错误。Manus 等先进架构通过三层分层设计缓解了这一问题第 1 层原子层 (Atomic Layer)特点 仅保留约 20 个核心、高频、正交的工具。内容read file, edit file,browser_navigate, bash, ls、task 等。目的 确保模型最基础的交互能力稳定可靠。第 2 层沙箱工具层 (Sandbox Utilities)核心思想 去工具化。不再为每个程序如 ffmpeg封装独立的 Function Call 定义而是直接让 LLM 使用 bash 工具在命令行中调用预装程序。优势 将工具的具体定义排除在 Context 之外极大节省 Token 并降低混淆。案例对比视频处理 (FFmpeg)❌ 传统模式API 堆砌 开发者必须预定义 convert_video 等大量专用工具及其繁杂参数分辨率、码率等。结果 LLM 面对的是一个冗长且受限的工具列表 [file_read, convert_video, resize_image...]消耗大量 Token 且缺乏灵活性。✅ Manus 模式通用沙箱 开发者仅提供 bash 工具并写入提示词“如果你发现当前没有合适的工具请使用 /help 命令探测系统环境。” 执行流程判断用户请求处理视频LLM 扫描工具列表 [file_read, bash]发现没有视频工具。探测LLM 遵循预设提示通过 bash 执行 /help系统返回可用命令列表 (如 ffmpeg)。执行LLM 随即构建并执行 ffmpeg -i video.mov... 完成任务。底层还是渐进式披露的思想。第 3 层代码/包层 (Code/Packages)核心思想逻辑封装。类似 Huggingface Smolagents 的理念。场景 针对复杂的串行逻辑。解决方案 不再进行 3 次 LLM 往返交互 (Roundtrips)而是直接提供 Python 库让 Agent 编写一段动态脚本一次性执行所有步骤。如下图假如用 tool可能一个简单的问题“帮我查看每个国家换算成美元后的手机价格找过最便宜的国家”需要上百次的 tool 调用但用代码其实只是十几行代码的循环。既然通用型 Agent 的架构已经如此强大我们如何将其适配到特定的垂直业务场景中1.业务知识技能化 (Skills via File System) 将业务文档、SOP标准作业程序抽象为 Skills存储在 Agent 的文件系统中。模型根据任务需求按需动态加载Load on Demand而非一次性塞入。2.业务接口 MCP 化 (MCP) 将企业的业务 API 封装为 MCP (Model Context Protocol) 服务。Agent 可以像连接外设一样按需连接和调用这些 Server。3.提示词精细化 (Fine-grained System Prompts) 分别针对 Main Agent负责调度和 Sub Agent负责执行编写极度详细的 System Prompt约束其行为边界。四、业务中的思考如何将现有 Workflow 升级为 Agent其实很简单仿照 claude 的 deep research prompt[13] 就好了。claude deep research 就是一个很典型的 main-agent/sub-agent 架构只有三个 prompt一个 main agentlead agent一个 subagent一个是生成文章后处理引用信息的 agent 最重要的就是 main-agent/sub-agent 。模仿 Claude Deep Research 的 Prompt 架构。我们可以将大量复杂的业务流程和决策逻辑通过极度详尽的 System Prompt 沉淀到 Main Agent 的认知体系中。很多人之所以不相信这种方式有效往往是因为他们没有使用最 SOTA 的模型claude4.5、 gemeni3 、 gpt5.2。假如确实没有拿到最 SOTA 的模型那就把任务难度降一层级吧。在那些没那么复杂的业务上做尝试。相较于传统微调SFT动辄两周的长周期 —— 在此期间需要投入大量时间进行数据清洗、人工标注和反复训练。Agent 模式的开发路径直接跳过了最耗时的数据准备环节将迭代周期从 “周级” 压缩至 “天级”。其核心逻辑本质是通过消耗 token 的方式来换取效果的快速迭代与提升。个人感觉26 年要多尝试这种开发姿势了。五、25 年我的 Agent 探索新路25 年过去了随着更强的模型现在新发布的模型例如 deepseekv3.2、kimi 2 thinking、gemini3 它们都一定会宣称自己是一个 agent native model用了大量 agent 的数据来做训练。回顾这一年思考路径随着技术演进而不断深化2025 年 2 月 受 OpenAI 发布 DeepResearch 的启发我思考了 Agent 的形态写下《25 年什么样的 Agent 会脱颖而出简单胜于复杂》[14]。2025 年 4 月深入业务场景实践围绕“端到端复现 Deep Research”撰写了三部曲《端到端的训练怎么复现 Deep ReSearch上 先从 Deep Search 做起》[15]《端到端的训练怎么复现 Deep ReSearch中 围绕着”Deep”解构 Jina 项目的实现》[16]《端到端的训练怎么复现 Deep ReSearch下 前沿的产品形态》[17]2025 年 8 月上下文工程是本质写下《为什么我们需要 Context Engineering》[18]期间紧跟 Anthropic 等厂商的最佳实践实践看到有感触的就写《Anthropic为 Agent 编写高效的工具》[19]《Anthropic如何建设有效的上下文》[20]《我看懂了通义 Deep Research 的进化史》[21]《Skills 让你的 Agent 从”可用”变”好用”》[22]《Sub Agent As Tool 的 Agent 设计思想》[23]如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】