自 2024 年 AI Agent 概念走红以来行业里一直存在两种极端声音一种说“Agent 只是套壳的 Prompt 工程”另一种说“Agent 是通向 AGI 的关键路径”。从 2026 年的视角往回看这两种说法都不够准确。真正在发生的变化是Agent 开发正在从“调用模型 API”走向“构建复杂业务系统”。如果你只停留在写 Prompt、调 LangChain 链路的阶段会发现很难应对企业级项目里的多步骤决策、工具调度、知识库融合和异常恢复。这篇文章要聊的是一套更完整的 AI Agent 工程化学习路径Agent Skills LangGraph RAG Prompt 全流程落地。无论你是刚入门 AI 开发还是已经在做 LLM 应用但感觉遇到了瓶颈这篇文章都会帮你理清“Agent 开发到底在学什么”并提供一个可以直接跑通的最小示例。在展开技术细节之前先给一个明确判断2026 年AI Agent 开发的竞争点已经从“谁更会用 Prompt”转移到了“谁更会设计 Agent 的工作流、状态管理和工具调用”。 换句话说Prompt 仍然是地基但决定项目上限的是 Agent 的架构能力和工程化能力。把这篇文章看完你能理解 LangGraph 在 Agent 开发中的位置能搞懂 Agent Skills 和普通工具函数有什么区别能知道 RAG 和 Agent 结合时真正容易出错的环节在哪里还能拿到一套适合个人学习和企业落地的实践路线。1. AI Agent 到底是什么不只是“会聊天的程序”很多初学者会把 AI Agent 理解为“一个更聪明的聊天机器人”这其实是最大的误区。聊天机器人是“你说一句它回一句”本质是单轮的文本生成。而 AI Agent 的核心特征是自主决策它拿到一个目标之后能够自己判断需要调用哪些工具、按什么顺序执行、中途遇到错误如何修正直到完成整个任务。举一个简单的例子。你让 ChatGPT 帮你写一篇行业分析报告它直接生成一篇。你让一个 AI Agent 帮你完成同样的事它的工作流可能是调用搜索工具获取最新的行业数据和政策文件。调用文档解析工具读取几份 PDF 报告。调用数据库查询工具补充内部业务数据。综合所有材料生成报告大纲。根据大纲逐节撰写再统一校对格式。整个过程模型不仅要理解任务还要持续维护一个“当前做到哪一步、下一步该做什么”的状态。这个状态管理能力就是 Agent 和普通 LLM 应用之间最本质的区别。为了支撑这种能力Agent 技术栈在 2026 年已经形成了一个相对清晰的分层层级解决什么问题典型技术认知层理解任务、生成内容、决策规划LLM、Prompt Engineering技能层复用原子能力、封装领域操作Agent Skills、MCP、Function Calling编排层管理多步骤流程、状态、分支和循环LangGraph、自研状态机知识层接入外部知识和私有数据RAG、向量数据库、Agentic RAG工程层部署、观测、评测、权限控制LangSmith、Langfuse、监控体系后面所有内容都会围绕这个分层展开。2. Prompt 工程的进阶从“写提示词”到“设计决策规则”2.1 Prompt 是 Agent 的操作系统指令总有人问2026 年了Prompt 工程是不是已经过时了答案是没有但它的形态变了。在 Agent 架构里Prompt 不再只是一段“约束模型说话风格”的文字而是整个 Agent 的决策规则系统。举一个真实场景。你在做电商客服 Agent一个用户说“我上周买的手机屏幕碎了想退货”。如果只用 Prompt 约束模型它大概率会给出一个礼貌的退货指引。但在 Agent 场景里这个输入会被拆解成多个决策点用户的订单是否在退货期内屏幕碎裂属于质量原因还是人为损坏是否需要用户上传照片进行自动质检退款路径是原路退回还是补偿优惠券这些决策规则必须写进 System Prompt配合工具调用来完成。所以Prompt 工程在 Agent 时代真正要解决的是如何让模型在每一步都做出符合业务预期的决策。2.2 System Prompt 的结构化设计范式从大量企业级项目反馈来看一套合格的 Agent System Prompt 至少应该包含四个模块角色与目标定义你是什么 Agent负责完成什么目标。输入输出约束接受什么格式的信息必须输出什么结构。决策规则遇到什么情况走哪个分支哪些操作必须经过确认。工具使用边界哪些工具允许调用调用的前提和限制是什么。# 一个简化的客服 Agent System Prompt 结构 SYSTEM_PROMPT 你是一个电商售后客服 Agent。你的目标是解决用户的售后问题。 ## 决策规则 1. 如果用户要求退货先查询订单状态。 - 订单在退货期内 - 引导用户提交退货申请 - 订单超期 - 说明政策并建议申请售后维修 2. 如果用户上传了商品图片调用 image_check 工具进行质检。 3. 质检结果属于人为损坏 - 告知无法免费退货引导付费维修。 4. 质检结果属于质量问题 - 直接生成退货工单。 ## 工具使用边界 - 只有完成订单查询后才能调用 image_check 工具。 - 任何涉及退款的操作必须返回确认页面不得直接执行。 这里真正重要的不是 Prompt 写得多漂亮而是规则可执行、分支可枚举、边界可控制。如果你发现 Agent 经常跑偏首先要检查的不是模型能力而是这里的决策规则有没有穷尽真实业务场景。3. Agent Skills把“技能”和“工具”分开是工程化的一大步3.1 从 Function Calling 到 Agent SkillsFunction Calling 解决了“模型能调用函数”的问题但实际开发中会遇到一个尴尬一个函数往往太小难以表达一个完整的业务能力。比如你有一个send_email函数它只是发送一封邮件。但要完成“给客户发送一封含附件的合同签署提醒邮件”你需要连续调用多个函数还要处理格式转换、附件上传、失败重试等逻辑。Agent Skills 解决的就是这个问题。它把一组相关的工具调用、上下文处理逻辑和 Prompt 指令打包成一个可复用的技能单元。你可以在不同 Agent 中挂载同一个 Skill就像给不同机器人安装同一个“技能包”。主流的 Skill 形式有两种MCPModel Context Protocol技能包通过 MCP 协议暴露标准化的工具接口支持跨平台复用。LangGraph 预编译子图把一个完整业务动作封装成子图作为可复用的节点。3.2 一个 Agent Skill 应该包含什么从工程实践看一个合格的 Agent Skill 至少包含四个部分技能描述说明这个技能做什么、在什么条件下触发。输入参数定义模型调用技能时需要提供哪些参数。工具调用链技能内部会调用哪些外部工具。错误处理调用失败时如何重试、降级或上报。{ skill_name: after_sale_refund, description: 处理用户退款申请包含订单校验、退款资格检查和退款流程发起, trigger: 用户明确表达退款意愿并已完成订单查询, parameters: { order_id: string, user_id: string, reason_code: string }, workflow: [ validate_order_status, check_refund_eligibility, calculate_refund_amount, create_refund_ticket ], error_handling: { order_not_found: 返回错误信息并要求用户核对订单号, refund_denied: 返回具体拒绝原因并提供申诉入口 } }这里体现的设计核心是让模型只负责决策和语言交互把可枚举、可测试的逻辑放进 Skill 里。这样你的业务逻辑可以被单元测试覆盖模型的不确定性对业务风险的影响也会大幅降低。4. LangGraph 为什么是 Agent 编排层的核心选项4.1 LangChain 与 LangGraph 的区别很多初学者会困惑LangChain 和 LangGraph 到底该学哪个简单说LangChain 是“链条”思维适合线性流程LangGraph 是“图”思维支持循环、分支、状态持久化更适合复杂 Agent。对比维度LangChainLangGraph核心抽象Chain链Graph图流程控制线性管道分支、循环、并行状态管理弱链间传递有限强支持 Checkpoint 持久化适合场景简单的 LLM 调用流程多步骤、多决策的 Agent调试能力一般支持逐步可视化追踪如果只是做一个“读取文件 - 总结 - 输出”的小工具LangChain 够用了。但如果你想做一个能自主规划任务、循环调用工具的 Agent选 LangGraph 更合适。4.2 LangGraph 的核心概念用最简单的话解释 LangGraph它让你把 Agent 的工作流画成一张图图里的每个节点是一段处理逻辑节点之间的边是流转条件。它最值得关注的两个特性是状态机机制Agent 每一步的执行结果都会更新到一个全局状态对象里后续节点可以读取。这让 Agent 有能力“记住上下文”。Checkpoint 持久化可以把状态保存到数据库任务中断后可以从断点恢复。这对企业级长任务非常重要。# langgraph 基本节点示例概念演示 from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: list order_info: dict refund_approved: bool def query_order(state: AgentState): # 模拟查询订单 return {order_info: {id: A1001, status: delivered, days: 5}} def check_refund(state: AgentState): order state[order_info] # 简单规则发货 7 天内可退 approved order[days] 7 return {refund_approved: approved} def create_ticket(state: AgentState): if state[refund_approved]: return {messages: 退款申请已创建} return {messages: 不符合退款条件} graph StateGraph(AgentState) graph.add_node(query_order, query_order) graph.add_node(check_refund, check_refund) graph.add_node(create_ticket, create_ticket) graph.add_edge(query_order, check_refund) graph.add_edge(check_refund, create_ticket) graph.add_edge(create_ticket, END)这个示例虽然简化但它展示了 LangGraph 的写作范式先定义状态结构再定义节点函数最后连接成图。真实项目里节点函数内部可以调用任意 Python 代码、RAG 检索、外部 API 或 Agent Skill。5. RAG 与 Agent 融合Agentic RAG 才是企业落地的关键5.1 传统 RAG 的局限RAGRetrieval-Augmented Generation检索增强生成这个概念已经火了一段时间。它通过检索外部知识库来增强 LLM 的回答质量解决了模型“不懂私有知识”的问题。但传统 RAG 有一个天然短板检索是一次性的无法根据问题动态调整查询策略。举个例子。用户问“我们公司去年 Q3 的营收是多少和 Q2 相比有什么变化”。传统 RAG 的做法是把整个问题拿去向量检索可能召回一堆不相关的文档。因为它不会拆解问题不知道应该先找 Q3 财报再找 Q2 财报再做对比分析。5.2 Agentic RAG 的流程设计Agentic RAG 的思路是让 Agent 来调度检索过程。它不再是一次性“查了就答”而是分析用户问题判断需要哪些数据源。决定检索策略向量检索、关键词检索还是 SQL 查询。执行第一轮检索评估结果是否足够回答问题。不够就继续第二轮检索或调整查询语句。全部材料齐了再组织最终答案。这种模式下RAG 从“一个检索模块”变成了“一个由 Agent 决策驱动的复杂流程”。企业知识库问答、智能客服、内部数据分析这类场景用 Agentic RAG 的效果会明显优于传统 RAG。# Agentic RAG 的查询重写示例伪代码 def agentic_retrieve(question: str, vector_store, sql_engine): # Step 1: 判断问题类型 question_type llm_router(question) if question_type sql: # Step 2: 生成 SQL 并查询结构化数据 sql llm_to_sql(question) result sql_engine.query(sql) return result elif question_type hybrid: # Step 3: 先向量检索再判断需要补充的数据 docs vector_store.similarity_search(question, k5) missing_info detect_missing_info(question, docs) if missing_info: extra_docs vector_store.similarity_search(missing_info, k3) docs.extend(extra_docs) return docs这里的关键不是代码本身而是把“如何检索”从固定流程变成了模型决策。当然这也意味着你需要对模型决策的结果做更多校验避免它选错检索路径。6. 从零跑通一个最小 Agent 项目工伤报告分析助手为了让前面的概念落地这一节带大家从零搭建一个最小的 Agent 项目。这里选择的主题是“工伤报告分析助手”背景设定是企业内部有一批工伤事故 PDF 报告Agent 需要判断事故等级、提取关键信息、生成整改建议。这个项目同时用到了 LangGraph流程编排、RAG报告检索和 Agent Skills质检技能封装适合作为学习模板。6.1 环境准备本文示例代码使用 Python 3.10 以上版本需要安装以下依赖pip install langgraph langchain-core langchain-openai chromadb pypdf实际运行时你需要准备一个 OpenAI 兼容的模型服务地址和 API Key。如果使用本地模型服务或其他厂商模型只需替换 LangChain 的模型类整体流程不变。6.2 项目结构和核心代码agent_demo/ ├── main.py ├── skills/ │ ├── report_parser.py │ └── risk_assessor.py ├── rag/ │ └── vector_store.py └── data/ └── sample_reports/第一步定义 Agent 的状态结构# main.py from typing import TypedDict, List from langgraph.graph import StateGraph, END class ReportAgentState(TypedDict): report_paths: List[str] parsed_reports: List[dict] risk_levels: List[str] suggestions: List[str] final_report: str第二步封装一个 RAG 检索工具用于从历史报告中检索相似案例# rag/vector_store.py from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter def build_vector_store(pdf_dir: str): docs [] for pdf_path in glob.glob(f{pdf_dir}/*.pdf): loader PyPDFLoader(pdf_path) docs.extend(loader.load()) splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(docs) vectordb Chroma.from_documents( chunks, embeddingOpenAIEmbeddings() ) return vectordb def search_similar_cases(question: str, vectordb, k3): return vectordb.similarity_search(question, kk)第三步定义节点函数。这里模拟了四个节点解析报告、风险评估、检索相似案例、生成整改建议。# main.py from rag.vector_store import build_vector_store, search_similar_cases def parse_reports(state: ReportAgentState): parsed [] for path in state[report_paths]: # 真实项目中这里调用 skills/report_parser.py 解析 PDF parsed.append({path: path, cause: 机械伤害, severity: 中度}) return {parsed_reports: parsed} def assess_risk(state: ReportAgentState): levels [] for report in state[parsed_reports]: sev report[severity] if sev 轻度: levels.append(低风险) elif sev 中度: levels.append(中风险) else: levels.append(高风险) return {risk_levels: levels} def search_similar(state: ReportAgentState): vectordb build_vector_store(data/sample_reports) query 最近发生的机械伤害事故如何处理 cases search_similar_cases(query, vectordb) # 简化只记录检索到的相似案例数量 return {suggestions: [f参考历史案例: {cases[0].page_content[:50]} for case in cases]} def generate_report(state: ReportAgentState): final \n.join([ f报告路径: {p} for p in state[report_paths] ]) final \n \n.join(state[suggestions]) return {final_report: final}第四步组装 LangGraph 图# main.py graph StateGraph(ReportAgentState) graph.add_node(parse_reports, parse_reports) graph.add_node(assess_risk, assess_risk) graph.add_node(search_similar, search_similar) graph.add_node(generate_report, generate_report) graph.add_edge(parse_reports, assess_risk) graph.add_edge(parse_reports, search_similar) graph.add_edge(assess_risk, generate_report) graph.add_edge(search_similar, generate_report) graph.add_edge(generate_report, END) app graph.compile() if __name__ __main__: result app.invoke({ report_paths: [data/sample_reports/事故A.pdf] }) print(result[final_report])6.3 如何验证 Agent 是否工作正常运行python main.py预期输出是一段整合了风险等级和相似案例信息的文字。这里重点提醒两件事先跑通最小链路再扩展技能。第一次运行时去掉所有外部依赖用假数据验证 LangGraph 的节点流转和状态传递是否正确。打开 LangGraph 的调试追踪。LangGraph 支持逐步查看每个节点的输入输出出现问题时先看是哪个节点抛异常再判断是模型问题还是逻辑问题。7. 学习路线规划零基础到企业实战怎么走很多读者问我想从零开始学 AI Agent应该按什么顺序这里给出一条经过验证的六阶段路线。7.1 第一阶段LLM 基础与 Prompt 工程1-2 周先搞清楚大模型的基本能力边界学会结构化地写 Prompt。这个阶段的核心不是写花哨的提示词而是学会拆解任务、定义输入输出、设计 few-shot 示例。建议每天做 5 个 Prompt 优化练习覆盖总结、抽取、改写、推理、代码生成五类任务。7.2 第二阶段掌握 Agent 核心概念1 周理解 Tool Calling、System Prompt、上下文管理、多轮对话状态。这个阶段可以拿一个现成的 Agent 框架跑几个 Demo重点观察模型在什么情况下会调用工具、什么情况下会拒绝调用、什么情况下调用错误。7.3 第三阶段LangChain 与 LangGraph 基础2-3 周先学 LangChain 的 Chain、Retriever、Memory 这几个基础组件再切换到 LangGraph 学习 StateGraph、节点、边和状态管理。理解 LangGraph 的状态机制是区分“会用”和“理解”的分水岭。7.4 第四阶段RAG 实战2 周从搭建向量数据库开始做文档加载、切分、向量化、检索、重排。重点学会分析检索效果理解召回率、准确率、chunk 大小对回答质量的影响。如果做的是企业知识库场景还要学会权限控制和数据更新策略。7.5 第五阶段Agent Skills 与多 Agent 协作2 周学习如何把工具调用封装成可复用 Skill掌握主从 Agent 架构。真实业务里一个 Agent 往往不够需要设计主管 Agent 调度多个子 Agent 分别处理不同任务。7.6 第六阶段企业级工程化持续关注评测、日志、成本控制、安全合规、灰度发布。企业项目和 Demo 的最大区别不是模型能力而是可观测性和可控性。AI Agent 在正式上线之前必须能回答一个问题如果它做错了你能不能快速定位、快速止损。8. 常见问题与排查思路问题现象可能原因排查方式解决方案Agent 不调用工具一直在聊天System Prompt 中工具使用规则不够明确查看模型输出的完整请求消息在 Prompt 中明确“必须调用工具才能回答”并给出触发条件示例Agent 调用了错误的工具工具描述不清晰或参数定义模糊检查工具名称和描述是否被模型正确理解重新编写工具描述增加参数约束和示例值LangGraph 任务执行到一半中断节点函数抛异常或状态字段缺失查看 LangGraph 追踪日志定位失败节点为每个节点补充 try-except并检查状态字段的读写顺序RAG 检索结果不相关chunk 切分粒度过大或过小检查切分后的文档片段内容调整 chunk_size 和 overlap尝试按语义段落切分Prompt 被安全策略拦截提示词内容涉及敏感指令查看模型服务返回的违规信息简化 Prompt 表达避免包含明令禁止的内容Agent 回答过于冗长未在 Prompt 中限制输出长度检查生成参数 max_tokens 和 Prompt 约束设置输出格式模板和简明性要求状态管理混乱上下文丢失未正确使用 LangGraph 的持久化机制检查 Checkpoint 配置是否正确使用 MemorySaver 或数据库持久化方式保存状态9. 最佳实践企业级 Agent 开发的六个建议第一建立评测集。所有 Agent 项目都应该在开发第一天就收集 50-100 条典型输入标注好预期行为作为回归评测集。不要等开发完成再补那时你已经无法判断改动是好是坏。第二Prompt 和代码分开管理。不要把长 Prompt 直接写在 Python 字符串里。建议放到独立配置文件或 Prompt 管理平台方便不同角色协作维护。第三控制模型决策成本。在 LangGraph 里有些节点其实不需要 LLM 参与用普通 Python 逻辑判断就够了。只在需要理解语义、生成内容的时候调用模型能显著降低成本。第四做好可观测性。每一次模型调用、工具调用、状态变化都应该有日志。建议接入 LangSmith、Langfuse 这类工具否则线上问题排查会非常痛苦。第五安全边界前置。Agent 能调用的工具必须做权限控制涉及资金、个人信息、删除操作等敏感动作必须二次确认。工具层要做输入校验不让模型任意拼接命令。第六避免过度设计。先用最简单的流程实现业务闭环再逐步增加分支和 Skill。一上来就设计一个复杂的 Multi-Agent 架构大概率会把自己绕进去。10. 总结Agent 学习的关键转折点把这篇文章的核心观点浓缩成一句话AI Agent 开发真正难的不是让模型“懂”而是让系统“稳”。Prompt 决定 Agent 的下限LangGraph 决定 Agent 的上限RAG 决定 Agent 的知识边界Agent Skills 决定 Agent 的能力复用效率。这四个部分不是彼此孤立的技术点而是一条完整的工程链路。对于刚入门的朋友建议先不要追求复杂的 Multi-Agent 架构。从今天的最小示例开始把一个单 Agent 的工作流跑通加上检索加上技能封装再逐步扩展到多任务协同。每一步都确认自己能解释“为什么这样设计”比追求“用了多少新技术”重要得多。对于已经在做企业项目的读者建议复盘一下当前项目的瓶颈在哪里。如果模型经常答非所问先优化 Prompt 和评测集如果业务流程无法灵活调整先看编排层是否足够清晰如果知识库效果不行先扎下去分析 RAG 的检索链路。AI Agent 的学习路径没有捷径但有一条清晰的路线概念 - 原理 - 最小实现 - 场景实战 - 工程化反思。按这个节奏走你学到的不是一堆零散的名词而是一套能真正支撑企业级项目的方法论。
