本文记录了作者利用AI Agent实现开源应用Helm Chart自动化生成的探索历程。从最初"全自主决策"Agent的失败，到设计"结构化工作流"Agent的成功实践，文章详细阐述了AI Agent的角色定位、能力边界、行为范式及Prompt工程的重要性。通过引入"部署蓝图"中间层和"自愈循环"修复机制，实现了从docker-compose到Helm Chart的自动化转换，为AI在工程领域的应用提供了有价值的实践经验。

---

本文主要阐述作者通过亲身实践，探索利用AI Agent实现开源应用Helm Chart自动化生成的实践历程。

引言

这事儿得回到两周前，彼时我刚入职，正兴致勃勃地想接下来会做些什么，周会上说到新需求的进展遇到了一个小问题——面临上百个开源应用的k8s部署适配，TL表示现在啊，AI提效是关键，“咱们能不能搞个AI？”“就给它一个开源应用，它一下自己部署全了。”

在那个瞬间，我脑海里闪过的一个宏大的图景——一个全能的应用部署agent，好吧冷静下来，还是聚焦于一个小的开始，k8s部署物的自动生成。（输入一个开源项目（如 GitHub 链接），AI Agent 能够分析项目，并输出一个可直接部署的 Helm Chart 包。）

我一头扎进了 AI Agent 的世界。这个过程，比我想象的要曲折。经历了初期“AI 无所不能”的天真幻想，也体验了Agent 陷入无限循环时的茫然。最终，磕绊地实现了一个初级的最小可行性方案。现在把这段尚在进行时的探索之旅记录下来，作为个人学习的总结，也希望能和大家交流，得到前辈们的指点。

怎么做一个agent

定义 Agent 的角色

万事开头难，尤其是做一个没有接触的东西。最初的我理解的agent模样：

只要提供一堆工具和prompt，agent就可以自行探索-分析-决策-执行直到解决任务。尽管从宏观角度上来说这样并没有错，但这却让我踩进了第一个坑——让LLM控制一切：给LLM一堆工具让它自由发挥企图它能够按照心里的目标实现，而让LLM控制一切的结果就是，不完善的prompt和tools带来了无限循环。

LangChain给了一个宏观指导，它把构建 Agent 的过程分成了几个阶段，从定义到部署。

(图源: https://blog.langchain.com/how-to-build-an-agent/）

回头看，我前期的混乱，本质上就是在 Stage 1: Define 阶段的无所适从。我一心想快速实现Stage 3: Build MVP，却忽略了最根本的问题：在这个任务里，AI 的边界到底在哪里？

我应该让 AI 做什么？又应该让工程代码做什么？

这个问题，应该是 AI 应用探索的起点。前期我东一榔头西一榔头，一会儿尝试让 AI 自己写 shell 脚本去扫描目录，一会儿又让它去决策先分析哪个文件，结果就是 AI 的表现极其不稳定，输出的结果惨不忍睹。

在踩了坑之后，我才明白，Define 阶段要回答的，不仅仅是“做什么功能”，更是“AI 以何种方式参与工作”。

AI 能力的边界

尽管从理想情况来说，一切人能够清晰衡量和验证的事物都能被AI解决（源自Jason wei），但应用落地还是要受限于当下的模型。有可能随着模型的发展，一句话的prompt就能让ai实现当下多agent完成的任务。个人实践来看，AI 是在做分析者（Analyst） 与 决策者（Decision-Maker）。

• 作为分析者：这是 AI 最容易胜任的角色。AI 的核心任务是感知和理解。它不直接执行任何变更操作，阅读庞大的信息迅速抓住信息的重点。例如，它可以阅读持续监控 Prometheus 指标和 Pod 日志，聚合所有相关信息——包括异常指标、错误日志、相关的变更事件，然后生成一份根本原因分析报告。尽管依然有“幻觉”的出现，但现在的AI在这个方面已经做得不错了。
• 作为决策者：让 AI 做决策，意味着它需要对环境有深刻的理解，甚至具备一定程度的“常识”，在已知的模型能力下，往往和高质量的prompt和上下文强相关。要让 AI 胜任这个角色，必须给它提供一套明确的行动框架：清晰的工具集、详尽的工具使用场景、固定的工作流，甚至要细化到每个决策节点的触发时机。 比如，不能简单地告诉 AI “更新服务”，而是要将这个任务拆解成一个它能理解的工作流。在这种情况下，执行越小越清晰任务的agent往往比执行复杂任务的agent表现得更好，也更容易控制。

Agent的行为范式

业界已经有很多关于 Agent 行为范式的探讨：

ReAct (Reasoning and Acting)《ReAct: Synergizing Reasoning and Acting in Language Models》：https://arxiv.org/pdf/2210.03629

(图源: ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models)

ReAct 的核心是 Thought -> Action -> Observation 的循环 。LLM 思考一下，决定调用一个工具（Action），然后观察工具返回的结果，再进行下一轮思考 。该框架本质上创建了一个反馈循环，每次完成此循环时（即每次代理采取行动并根据该行动的结果进行观察时），代理必须决定是否重复或结束循环。LangGraph 中的 ReAct 代理模块通过预定义的系统提示实现，与该模块一起使用的 LLM 不需要任何其他示例即可充当 ReAct 代理。

请尽力回答以下问题。您可以使用以下工具：

plan-and-execute

（图源：https://github.com/langchain-ai/langgraph/blob/main/docs/docs/tutorials/plan-and-execute/plan-and-execute.ipynb）

plan-and-execute旨在克服ReAct类代理的局限性，通过在执行任务前明确规划所有必要步骤。这种方法旨在提高效率、降低成本并提升整体性能。其核心工作流程包含三个阶段：

• 规划阶段 ：接收用户输入，并生成一个用于完成大型任务的多步骤计划或任务清单；
• 执行阶段 ：接收计划中的步骤，并调用一个或多个工具来按顺序完成每个子任务；
• 重规划阶段：根据执行结果动态调整计划或返回；

manus的Agent像是借鉴了这种思路，首先生成任务清单，再对着清单逐个执行。

ReWOO（ Reasoning WithOut Observation ）

（图源：https://github.com/langchain-ai/langgraph/blob/main/docs/docs/tutorials/rewoo/rewoo.ipynb）

ReWOO是一种创新的增强语言模型 (Augmented Language Model, ALM) 框架。它将复杂任务的解决过程分解为三个独立的模块：

• 规划器 (Planner)： 基于 LLM 推理，提前生成任务蓝图（步骤顺序与逻辑），无需工具实时反馈。
• 执行器 (Worker)： 按蓝图并行调用外部工具（如搜索、计算器），收集证据。
• 求解器 (Solver)： 综合分析蓝图和执行证据，生成最终答案（含纠错总结）。

ReWOO 最显著的特点是拥有一个独立的 Solver 模块。它专门负责整合规划意图与工具执行结果，屏蔽 Worker 的执行细节，直接基于蓝图和证据生成最终答案；在执行阶段（Worker 步骤），ReWOO 不查看外部工具返回的中间结果细节。

与 Plan and Execute 关键区别：

• ReWOO Worker 只负责执行工具调用，无需 LLM 驱动。
• ReWOO 没有重新规划步骤（蓝图固定）。

Agent框架

Agent框架我没有进行过多的研究，还没有一个像springboot对java web那样绝对统治地位的框架出现，完全可以自行实现一个简易的Agent框架，构建LLM + Tools + Workflow的组合。通过编写一些“胶水代码”，手动管理模型的输入输出、调用外部工具（如API或数据库），并控制整个任务的流程。当然使用一个成熟的框架能够更快地聚焦于任务业务部分。社区中已经涌现出许多优秀的Agent框架，我使用的是LangChain和LangGraph，当前阶段还不需要维护非常复杂的逻辑。

prompt工程

我最初也曾低估了Prompt工程的复杂性，认为它不过是“提需求”的简单环节。但当一个初步可行的框架和流水线搭建起来后，所有后续的质量优化、效果对齐和稳定性问题，几乎都聚焦到了与Prompt的持续“搏斗”上。这个过程耗时费力，且充满了不确定性。我们就像一个需求方，试图向一个能力强大但心智难以捉摸的第三方清晰地传达我们的意图，这其中的挑战远超预期。

实践中最大的感悟是，结构化是提升沟通效率的关键。通过类似README的格式，将Prompt拆解为角色（Role）、工具（Tools）、注意事项（Attention）、输出格式（Output）、执行逻辑（Logic）、具体要求（Requirements）等模块化指令，能够显著提高模型理解意图的准确率。这种方式的核心是尽可能地提供清晰、明确的上下文与背景信息，避免使用模糊的语言，从而帮助模型在庞大的可能性空间中，收敛到我们期望的输出范围。

即便采用了结构化的方法，我依然遇到许多“模型特色”的难题：

• “必须”并非绝对：指令中的“必须”、“一定”等强约束词，并不能保证100%被遵守。
• “重要”可能被忽略：模型有时会“抓不住重点”，无法准确识别我们强调的核心要素。
• 格式偶尔“叛逆”：即使明确规定了输出格式，模型有时仍会生成意料之外的“自由发挥”内容。

这些问题揭示了与大模型协作的本质：我们并非在编写具有确定性行为的代码，而是在通过自然语言引导一个概率系统。面对这种不确定性，需要更精细的策略，例如Few-short，即好的例子，清晰的逻辑链条和工具使用指南，迭代式优化等等。Prompt也不是越长越好，大模型的注意力可能会涣散。当然到Agent后考虑的不只是第一步的输入，而是上下文——所有输入给大模型的信息。

我还苦手于prompt工程，前期更多地追求可执行而不是质量。

GitHub - PandaBearLab/prompt-tutorial: chatGPT、prompt、LLM：https://github.com/PandaBearLab/prompt-tutorial

提示工程指南 – Nextra：https://www.promptingguide.ai/zh

设计的岔路口：三种 Agent 范式尝试

正是对这些底层逻辑的认知不足，才导致了我最初设计的失败。

“全自主决策”Agent的阵亡

这是我最开始的尝试，也是最符合“Agentic”的方案。我给它设定了一个大的目标，提供了一篮子工具（克隆仓库、读写文件、执行 Shell 等），然后写下了一段充满信任和期望的 Prompt：

你是一个云计算/容器研发工程师。你的任务是为一个开源项目生成一个可部署到Kubernetes 1.16+版本上的Helm Chart。

然后，我满怀期待地按下了回车。

Agent 确实“思考”了起来，它的 Thought 日志显示出一种努力工作的迹象。

• 决策瘫痪： 在面对一个有多个 docker-compose-xxx.yml 文件的仓库时，它会陷入长久的思考：“我需要阅读xxx文件来明确部署方案”“我没有找到xxx文件” ，这种思考让ai陷入了循环困境。
• 工具误用： 它会幻想出一些不存在的文件路径，然后固执地调用 read_file_content 工具，在得到一连串“文件不存在”的 Observation 后，它会感到困惑。
• 幻觉频出： 在深入分析一个复杂的 docker-compose 文件时，它可能会完全沉浸在理解某个服务的环境变量中，而多个文件可能存在的关联性让其产生“幻觉”。
• 无法掌控：在多次运行测试时也会有那么一次执行成功，那一次Agent不仅完美定位到了文件，甚至部署文件中错误的路径地址也被识破。通过列出文件结构树，一一阅读依赖文件，Agent为一个有7个依赖的复杂项目成功生成了部署物。然而只是昙花一现，可以说再也没有复现成功，Agent好像忘了自己曾经有那么聪明过。这也引申出AI存在的一个问题，每一次ReAct可能走上不一样的道路，而这可能是不可控的。

阵亡反思：遵循了基本的ReAct行为范式，AI出现了决策的脆弱性： 在一个多步骤、长链条的任务中，任何一步的 Thought 出现偏差（比如错误地判断了文件的重要性），都可能导致整个任务链走向一个无法挽回的死胡同。Agent 很容易陷入“我该干啥”的循环，或者在一个细枝末节上“钻牛角尖”。

这次的阵亡，让我体会到理想与现实的差距。对于一个步骤清晰、逻辑严密的工程任务，当前 LLM 的自主规划和纠错能力还不够成熟 。如果只提供AI一个简单的prompt，然后把一个宏大的、定义模糊的任务完全交予 AI，就像让一个只有短期记忆的聪明人去完成一项需要长期规划的系统工程。当然我觉得可能有很大的原因是prompt的锅，因为我既没有遵循提供给AI明确的流程的原则，也没有一个好的Few-short。但由于调试prompt实在是容易陷入“调试地狱”，且是可能是一个需要长期试验的过程，而简单prompt的结果离预期太远，在初探阶段我放弃了。

“结构化工作流”Agent

“全自主”的道路上行不通后，我换了一条道路。我意识到，我需要的不是一个“思考者”，而是一个在我的指导下，能把活儿干得漂亮的“执行者”。

于是，我放弃了让 AI 自由决策的幻想，转而设计了一套固定的、结构化的工作流。在这个范式里，人类负责定义“骨架”（Workflow），AI 负责填充“血肉”（Analysis & Generation）。并且为了快速获得测试结果，我将任务拆分，从一个项目的部署物生成到存在docker-compose项目的部署物生成。

我使用了 LangGraph 来编排这个工作流。下面是 MVP 的时序图：

最终输出：

输出

AI Agent工作流已构建。

中间语言“部署蓝图”

由于上一个“全自主决策”Agent的失败，我发现可能更需要流程的可控性。如果让AI自己生成部署蓝图，后续再遵循蓝图进行部署物生成，可能会让结果更为可控。

我引入了一个中间步骤：让 AI 先把项目的docker-compose内容翻译成一份详尽的、结构化的 “部署蓝图” JSON。

Prompt 长这样：

**角色**: 你是一位顶级的云原生解决方案架构师...

为什么设计这个“蓝图”？

1. 降低认知负荷，保证分析质量：让 AI 专注于“理解和分析”，而不是同时分心去想 Helm 的模板语法。这极大地提升了分析阶段的准确性。AI 在这一步表现得像一个真正的架构师，它能准确识别数据卷、配置文件、环境变量，并规划出对应的 K8s 资源。

2. 应对 Token 限制：复杂项目部署物的输出可能会超过模型的上限。为此采用了“迭代分片法”，它会先解析出里的所有服务，然后一个一个地调用 LLM 去生成每个 service 的蓝图片段，最后在代码层面将它们拼接成完整的蓝图。用工程手段弥补模型能力限制

3. 解耦与稳定：“蓝图”成了一个稳定、可调试的中间状态。如果最终生成的 Chart 有问题，我能清晰地判断，是“蓝图”生成错了，还是从“蓝图”到“YAML”的翻译步骤错了。这种解耦，对于调试和迭代至关重要。看似是使用了更多的prompt，但减少了调试的难度。

自我修复的“自愈循环”

“一次就写对所有代码”是神话，AI 也不例外。它生成的 Helm Chart 会有各种语法错误、命名不规范、模板引用错误等问题。设计一个自愈循环，并将其拆开单独形成一个工作逻辑，能够隔离开生成和修复环节，尽量避免大模型陷入无限循环，也防止出现“越修越错”。

把dry run这个确定性的、高质量的外部反馈，整合进了 AI 的工作流中。Agent 不再是“盲目生成”，而是有了“试错和修正”的能力 。在实践中，这个循环可能在20次内修复大部分常见的 Chart 问题，极大地提升了最终交付物的“可用性”。

这个“结构化工作流”方案，看起来是缺少了Agentic，但它僵硬而准确，最终成功地支撑起了我的 MVP。它让我明白，在当前的 AI 技术水平下，好的 Agent 应用，是工程设计与 AI 能力的精妙结合，而不是对 AI 的盲目放权。

这个部分正好贴合了Antropic的 Barry Zhang 提出 Agent 的概念，即在循环（Loop）中使用工具的模型。

（图源：https://generativeai.pub/use-n8n-like-a-pro-with-anthropics-6-simple-composable-patterns-for-llms-d601efe0f314）

“多 Agent 协作”

单一 Agent 完成一个端到端的复杂任务，它既要懂宏观架构，又要懂代码细节，还要会调试。在复盘 MVP 时，我觉得一个复杂任务，应该由一个 Agent 团队来协作完成 。

• 总指挥(Orchestrator): 接收原始需求，进行任务分解。

• Agent 1: 分析专家(Analysis Agent)：

• 输入: GitHub URL。

• 任务: 深入分析项目，阅读代码、README、甚至模拟人类去搜索相关文档，最终产出项目的核心元数据和一份或多种“可行的部署方案”（比如“方案A：用 Docker Compose 部署”，“方案B：用源码编译”）。

• 输出: 结构化的部署方案 JSON。

• Agent 2: 执行专家群(Execution Agents):

• Agent 2a: Docker Compose 执行器: 这就是我们 MVP 的核心。输入部署方案A，输出 Helm Chart。

• Agent 2b: 源码编译执行器: 输入部署方案B，负责生成包含编译步骤的 Dockerfile 和对应的 K8s YAML。

• Agent 2c: …

• Agent 3: 质检专家(QA Agent):

• 输入: 生成的部署产物（如 Helm Chart）。

• 任务: 进行静态检查（lint）、动态部署验证（在沙箱 K8s 环境中 helm install），并报告成功或失败。

• 输出: 质检报告。

这个“多 Agent 协作”模式，分析专家 就是 Planner，它负责思考和规划；执行专家群 就是 Workers，它们各自拥有一套专用工具，负责高效地执行具体的子任务 。

这种模式的好处是显而易见的：

• 单一职责： 每个 Agent 的目标更明确，Prompt 和工具集可以高度优化 。
• 可扩展性： 增加一种新的部署方式，只需要增加一个新的“执行专家” Agent，而不用修改整个系统。
• 健壮性： 单个 Agent 的失败不会导致整个系统崩溃，总指挥可以进行重试或切换到备用方案。

但是这也引入了新的问题，那就是多agent框架是怎样的，规范好用的多agent的传输协议，上下文和memory的设计等等，这又是一个很大的探索话题。

一个好的 Agent 到底长什么样？

大模型是不可控的。不是‘给LLM一堆工具让它自由发挥’，而是大部分由确定性代码构成，在关键决策点巧妙地融入LLM能力。

12-Factor Agents

初探让我对“一个好的 Agent 到底长啥样？”这个问题，有了更深刻的理解。12-Factor Agents：https://github.com/humanlayer/12-factor-agents?tab=readme-ov-file 这个项目为构建企业级、生产级的 Agent 提供了极好的指导原则。结合它的思想和我的实践，有一些感悟：

1.结构化上下文：上下文包括Prompt、说明、RAG 文档、历史记录、工具调用、记忆。这是做好一个agent大概率的选择，结构化的输入能让大模型更好地理解任务、执行任务，而结构化的输出也是为了下一步的输入。

2.单一职责： 这是我从“全自主 Agent”失败到“多 Agent 协作”思考的最大转变。试图构建一个无所不能的“瑞士军刀”式 Agent，可能导致样样通、样样松。而将任务拆解，让每个 Agent 专注于一个明确的、有边界的任务，是通往成功的首要法则 。

3.外部化状态管理：Agent 的思考过程应该是无状态的。所有的状态，都应该由外部的工作流引擎来管理 。这使得流程的每一步都可以被独立地调试、重试和观察。

4.解耦处理阶段：“蓝图”设计，就是这个原则的体现。将“分析理解”、“代码生成”、“检查修复”等阶段清晰地解耦，使得每个阶段都可以被独立优化，也让整个流程的复杂性得到了有效控制 。

5.可控性与可预测性： 这是 12-Factor 之外，个人的感悟。在工程领域的某些场景下，我们追求的往往不是 AI 的惊艳，而是它的可靠。一个好的 Agent，其行为应该是高度可控和可预测的。“结构化工作流”就是一种增强可控性的实践。我们应该通过清晰的流程、明确的指令和严格的输出格式。如何平衡AI的创造性和确定性是需要在一开始就确定的。

实践中的痛点

AI 可观测

市面上有很多ai可观测产品，这次使用的是LangSmith。LangSmith是LangChain团队推出的一个统一的可观测性与评估平台，旨在帮助开发者对AI应用进行调试、测试和监控。鉴于大型语言模型（LLM）本质上的非确定性，其内部运作机制难以完全理解，这给应用开发带来了独特的调试挑战。LangSmith通过提供LLM原生的可观测性能力，允许开发者分析调用链路（Traces），监控关键指标，从而追踪错误并优化应用性能。

这样的工具非常强大，它能让我清晰地看到 AI 的每一次思考、每一次工具调用 。但是缺少根因定位，比如能够分析错误链路（如工具调用失败→Token超限→LLM超时）。可能大模型调用发生错误或者停止了，但LangSmith 里的 AI Trace 一片祥和，所有步骤都是绿色的，而我可能需要猜测这一次是不是token超限了。

另外一个想法，是不是可以将 AI Trace 与业务观测体系融合，实现真正的端到端、一站式可观测。对于一个开源ai可观测来说这可能不是必须的，但对于应用管控来说我觉得是可以考虑的。

Prompt 工程的“炼丹术”困境

如果说 Agent 的代码是骨架，那 Prompt 就是灵魂。但这个“灵魂”的注入过程，带着一点玄学。

最佳实践的缺失与高昂的试错成本： OpenAI 的最佳实践：https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api给了很多好的指导，比如提供清晰指令、给出示例等。但具体到我的场景，“什么样的结构才是最省 Token 且信息量最高的？”“Few-shot 示例应该怎么说明？”这些问题没有标准答案，全靠一次次尝试 。而每一次尝试，都是时间、精力、token的消耗。

版本管理的噩梦： 我曾经为了修复一个因为 env_file 路径解析错误导致的 Bad Case，精心修改了prompt。结果，这个 Case 跑通了，但另外五个原本正常的 Case 全都挂了，AI 开始在其他地方产生幻觉。这种“牵一发而动全身”的效应，让 Prompt 的迭代和回归测试变得异常困难。想要一个能够清晰进行对比每一次输出结果的prompt调试工具，科学的版本管理和 A/B 测试框架。

可解释性的黑洞： 我改了 Prompt 里的一个词，Agent 的行为就变了。但为什么？是哪个词、哪个句子、哪个示例在起作用？它的权重是多少？这种解释性的缺失，让我们在调优时，更像是在“炼丹”，充满了偶然性和不确定性。

AI的“不确定性”

我把模型的 temperature 设为 0，希望能获得确定性的输出 。但在复杂的推理任务中，即使 temperature 为 0，模型在不同时间点对完全相同的输入，也可能给出细微差别甚至完全不同的推理路径。在需要精确输出的工程场景下，这种不确定性是致命的。我们该如何设计系统，来拥抱 AI 在“分析、发散”阶段的“有益的不确定性”，同时又能在“生成、收敛”阶段约束其行为，获得“可靠的确定性”？这或许是未来 Agent 需要解决的核心哲学命题。

其他

这次探索，除了在 Agent上的思考，还有一些需要复盘的东西。

• 一个项目拿到手，要先做设计，切忌东一榔头西一榔头。

在面对 AI 这种充满不确定性的新技术时，被“先跑起来看看”的冲动所支配。急于看到 AI 调用的神奇效果，却忽略了对整个工作流的顶层设计。结果就是，AI 的行为像一个无头苍蝇，修补工作也变得支离破碎。越是面对不确定的技术，就越需要一个确定性的工程设计作为锚点。

• 关于学会做减法，也学会做加法。

做减法指的是分解复杂问题，简化方案，从最小可行方案开始。当试图构建一个无所不能、能处理所有异常的“超级 Agent”时，很快就发现这是一个非常困难的任务。这时就要做减法：承认 AI 的局限性，将大的目标分解。这是在资源和时间有限的情况下的选择。

做加法指的是打破工具和方法的门户之见，用一种开放和务实的心态，组合一切可用的资源。最终的目标只有一个：让问题被解决，让项目能落地。

结语

这个探索其实才刚刚开始，现在的认知可能是片面的，尝试也可能是不到位的。再加上AI相关技术的快速发展，也许接下来会推翻今天的一些想法，但是目标是确定的——解决工程问题，让项目最终可靠地落地。不管是什么样的方法或是范式，它们都只是工具箱中的选项。我们的任务，就是在理解这些工具的边界和特性的基础上，遇到问题，分析问题，并用最恰当的方式去解决问题。

以上均是在探索开源应用快速部署上对Agent的探索，这里也提前做一个预告，阿里云EDAS产品将于9月底对首页进行改版，推出“开源项目一键部署”应用首页，敬请关注～

企业级分布式应用服务 EDAS

企业级分布式应用服务EDAS（Enterprise Distributed Application Service）是一个应用PaaS平台，一站式集成微服务、可观测、任务调度等技术；以专业易用的应用全生命周期管理、流量及容量治理等功能，配合业务视角的验收、资源管控与成本优化能力，助力企业应用架构云原生化升级。

界和特性的基础上，遇到问题，分析问题，并用最恰当的方式去解决问题。

以上均是在探索开源应用快速部署上对Agent的探索，这里也提前做一个预告，阿里云EDAS产品将于9月底对首页进行改版，推出“开源项目一键部署”应用首页，敬请关注～

零基础如何高效学习大模型？

你是否懂 AI，是否具备利用大模型去开发应用能力，是否能够对大模型进行调优，将会是决定自己职业前景的重要参数。

为了帮助大家打破壁垒，快速了解大模型核心技术原理，学习相关大模型技术。从原理出发真正入局大模型。在这里我和鲁为民博士系统梳理大模型学习脉络，这份 LLM大模型资料 分享出来：包括LLM大模型书籍、640套大模型行业报告、LLM大模型学习视频、LLM大模型学习路线、开源大模型学习教程等, 😝有需要的小伙伴，可以 扫描下方二维码免费领取🆓**⬇️⬇️⬇️

【大模型全套视频教程】

教程从当下的市场现状和趋势出发，分析各个岗位人才需求，带你充分了解自身情况，get 到适合自己的 AI 大模型入门学习路线。

从基础的 prompt 工程入手，逐步深入到 Agents，其中更是详细介绍了 LLM 最重要的编程框架 LangChain。最后把微调与预训练进行了对比介绍与分析。

同时课程详细介绍了AI大模型技能图谱知识树，规划属于你自己的大模型学习路线，并且专门提前收集了大家对大模型常见的疑问，集中解答所有疑惑！

深耕 AI 领域技术专家带你快速入门大模型

跟着行业技术专家免费学习的机会非常难得，相信跟着学习下来能够对大模型有更加深刻的认知和理解，也能真正利用起大模型，从而“弯道超车”，实现职业跃迁！

【精选AI大模型权威PDF书籍/教程】

精心筛选的经典与前沿并重的电子书和教程合集，包含《深度学习》等一百多本书籍和讲义精要等材料。绝对是深入理解理论、夯实基础的不二之选。

【AI 大模型面试题 】

除了 AI 入门课程，我还给大家准备了非常全面的**「AI 大模型面试题」，**包括字节、腾讯等一线大厂的 AI 岗面经分享、LLMs、Transformer、RAG 面试真题等，帮你在面试大模型工作中更快一步。

【大厂 AI 岗位面经分享（92份）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

【640套 AI 大模型行业研究报告】

【AI大模型完整版学习路线图（2025版）】

明确学习方向，2025年 AI 要学什么，这一张图就够了！

👇👇点击下方卡片链接免费领取全部内容👇👇

抓住AI浪潮，重塑职业未来！

科技行业正处于深刻变革之中。英特尔等巨头近期进行结构性调整，缩减部分传统岗位，同时AI相关技术岗位（尤其是大模型方向）需求激增，已成为不争的事实。具备相关技能的人才在就业市场上正变得炙手可热。

行业趋势洞察：

• 转型加速： 传统IT岗位面临转型压力，拥抱AI技术成为关键。
• 人才争夺战： 拥有3-5年经验、扎实AI技术功底和真实项目经验的工程师，在头部大厂及明星AI企业中的薪资竞争力显著提升（部分核心岗位可达较高水平）。
• 门槛提高： “具备AI项目实操经验”正迅速成为简历筛选的重要标准，预计未来1-2年将成为普遍门槛。

与其观望，不如行动！

面对变革，主动学习、提升技能才是应对之道。掌握AI大模型核心原理、主流应用技术与项目实战经验，是抓住时代机遇、实现职业跃迁的关键一步。

01 为什么分享这份学习资料？

当前，我国在AI大模型领域的高质量人才供给仍显不足，行业亟需更多有志于此的专业力量加入。

因此，我们决定将这份精心整理的AI大模型学习资料，无偿分享给每一位真心渴望进入这个领域、愿意投入学习的伙伴！

我们希望能为你的学习之路提供一份助力。如果在学习过程中遇到技术问题，也欢迎交流探讨，我们乐于分享所知。

*02 这份资料的价值在哪里？*

专业背书，系统构建：

• 本资料由我与鲁为民博士共同整理。鲁博士拥有清华大学学士和美国加州理工学院博士学位，在人工智能领域造诣深厚：

• • 在IEEE Transactions等顶级学术期刊及国际会议发表论文超过50篇。
  • 拥有多项中美发明专利。
  • 荣获吴文俊人工智能科学技术奖（中国人工智能领域重要奖项）。

• 目前，我有幸与鲁博士共同进行人工智能相关研究。

内容实用，循序渐进：

• 资料体系化覆盖了从基础概念入门到核心技术进阶的知识点。

• 包含丰富的视频教程与实战项目案例，强调动手实践能力。

• 无论你是初探AI领域的新手，还是已有一定技术基础希望深入大模型的学习者，这份资料都能为你提供系统性的学习路径和宝贵的实践参考，助力你提升技术能力，向大模型相关岗位转型发展。

  

抓住机遇，开启你的AI学习之旅！