AI Agent 开发常见概念汇总前言AI 演进地图AI Concepts1、Prompt2、Prompt Engineering提示词工程*Zero-shot Prompting / 零样本提示Few-shot Prompting / 少样本提示One-shot Prompting / 单样本提示Role Prompting / 角色提示System / User 指令分离Instruction Tuning / 明确指令Chain of Thought (CoT) / 思维链Prompt Chaining / 提示链多轮提示3、RAGRetrieval-Augmented Generation分块 / 切片Chunking / Text Splitting嵌入模型 / 向量化Embedding4、Context Engineering上下文工程5、Function Calling/Tool UseFunction Calling函数调用Tool Use工具使用6、四阶段对比总结PromptRAGContextFunction calling7、Agent8、MCPModel Context Protocol模型上下文协议9、25 AI Concepts前言AI的快速发展导致越来越多的行业引入AI提效IT行业更是大换水但是AI技术发展的迭代速度太快越来越多的概念涌入让新手很难理解谨以此篇文章记录自己学习所得欢迎各位对不足和错误之处进行指正。AI 演进地图AI Concepts1、Prompt本质上就是给模型的输入上下文中文翻译可以说成是提示词简单来说就是给ai发的消息分为两类user promt 和 system prompt。User Prompt用户提示词一般就是我们提出的问题或者想说的话System Prompt系统提示词主要用来描述AI角色、性格、背景信息等身份假设并不是真正的提示词单独拎出来就是System Prompt只要不是用户直接说出来的都可以放进System Prompt中。2、Prompt Engineering提示词工程*指的是通过系统提示词和用户提示词的组合来引导AI返回特定风格回复的做法。约束行为、减少错误。比如针对同一个模型做以下操作帮我写一个总结得到的结果就很一般。但是如果按照下面格式发送你是一名技术编辑。 请阅读下面内容。 要求 1. 提取三个关键结论 2. 每个结论不超过30字 3. 输出 JSON 4. 不要解释结果可能就完全不一样这也说明模型能力不是唯一变量输入上下文的设计也成为工程变量这就是Prompt Engineering。OpenAI于2022年11月公开推出ChatGPTOpenAI对它的定义非常明确“它是一个能够以对话方式与用户交互的模型”。ChatGPT的出现让AI从“API”变成了“产品”以前AI开发者调用API现在AI普通人直接对话。也正是ChatGPT的出现导致Prompt Engineering的概念大爆发于是出现了大量的提示词工程技巧。Zero-shot Prompting / 零样本提示含义不给模型任何 “示例”只直接描述任务、提出要求让模型从零开始生成答案考验模型本身的通用能力。请把下面这句话翻译成英文今天天气很好。Few-shot Prompting / 少样本提示含义在提示里给出少量通常 1–5 个标准示例示范 “输入→输出” 格式与风格模型照葫芦画瓢完成新任务效果显著优于零样本。优秀 - Positive 糟糕 - Negative 一般般 - Neutral “这个产品很不错。” -One-shot Prompting / 单样本提示含义Few-shot 的特例只给 1 个示例。Role Prompting / 角色提示含义一开始就给模型设定身份、立场、知识背景、语气风格让它以特定角色的视角和习惯回答提升针对性与专业性。你是一位资深 Python 工程师擅长用通俗比喻讲解复杂概念回答要简洁、附代码示例。System / User 指令分离含义把顶层规则 / 身份设定和具体任务内容分开写规则写在前面任务写在后面减少混淆、提升稳定性。【规则】你是初中数学老师讲解要浅显步骤清晰最后附 1 道练习题。 【题目】解这个方程2x 5 17Instruction Tuning / 明确指令含义用清晰、动词开头、无歧义的一句话说明核心任务避免模糊表述让模型第一时间知道 “要做什么”。❌ 差帮我看看这段文字 ✅ 好帮我把这段文字精简到 100 字以内保留核心意思语言口语化。Chain of Thought (CoT) / 思维链含义要求模型“先一步步讲清楚思考过程再给出最终答案”像人做题一样先写步骤显著提升数学、逻辑、推理题的正确率。一个球和球拍共 11 元球拍比球贵 10 元球多少钱请一步步思考后回答。Prompt Chaining / 提示链多轮提示含义把大任务拆成多轮对话—— 第一轮做 A→把 A 结果交给第二轮做 B→再做 C…每轮专注一件事比一次性长提示更稳、更好控。这一阶段暴露的问题写的再好的提示词也无法根治以下问题①知识有截止日不会自动更新大模型的知识冻结在训练数据截止日之后发生的事一概不知。②会一本正经地胡说八道幻觉问题模型不知道自己“不知道”遇到不懂的会强行编造提示词虽然能减少幻觉但无法从根本上解决----因为模型没有可信的事实来源③私有领域知识不会在训练数据中出现④上下文窗口永远不够装、也不够精确把所有资料一次性塞进提示词会导致token爆炸、成本飙升、关键信息被淹没在长文里。3、RAGRetrieval-Augmented Generation简单来说就是Prompt 只能 “教模型怎么思考”没法 “教模型知道什么事实”。 写得再精妙的提示词也变不出训练数据里没有、截止日后才出现、藏在内部文档里的信息。而且随着系统变复杂提示词会越来越长、越来越难维护 —— 变成 “提示词债务”版本混乱、测试困难、每次调用都付巨额 token 费。为了解决上述问题RAG出现了RAG 的核心思路“授人以鱼而不是只授人以渔”不强迫模型 记住一切 提问时先去外部知识库检索最相关的事实片段 把这些可信证据 你的提示词一起交给模型 模型照着 参考答案 来组织语言、回答问题两者关系RAG ≠ 取代 Prompt而是 “互补搭档”Prompt Engineering 依然重要负责 怎么回答、格式怎么写、语气如何 RAG 补上关键短板负责 依据什么事实来回答生产环境里两者几乎总是一起用检索到证据之后依然需要精心设计的提示词来引导模型准确、可靠地输出RAG含义将外部文档检索与大模型文本生成结合的技术框架提问时先从自有知识库取回相关片段再和问题一起交给大模型让模型基于可信资料作答。①先把文章拆成小段 ②把每一小段都通过Embedding转成向量并存进向量数据库中 ③把用户提问也通过Embedding转成向量并从向量数据库中选择语义接近的片段一起发给大语言模型。分块 / 切片Chunking / Text Splitting含义把长文档切分成较短的文本块Chunk控制长度适配模型上下文与向量限制。总的来说切块就是在输入文字前先对文字做预处理进行分割把整个文档切成很多小片段然后对每一小段都做Embedding让他们变成长度一致的数组向量此外还要把每个向量和原始文本片段对应关系保存起来向量数据库。嵌入模型 / 向量化Embedding含义把文本转为高密度数字向量语义相近的文本向量在空间中距离更近。输入是一段文字输出是固定长度的数组可以理解为对原始内容的有损压缩这一阶段暴露的问题此部分内容为AI总结有参考文献内容生成检索质量不可控漏检、误检、碎片化检索返回的片段可能不相关、不完整、过时或互相矛盾一旦第一步 “找错资料”后续再强的模型也答不准分块Chunking导致上下文断裂 ——答案分散在多个块、跨文档需要关联推理时RAG 表现显著下降无法处理 “跨文档综合、多跳推理” 类问题“词汇匹配但语义偏离”、“检索到错误版本 / 矛盾内容”、“重要信息被淹没”—— 统称检索固有的不可靠性幻觉没有根除只是 “转移来源”Wikipedia 明确指出RAG 不能完全阻止幻觉—— 即使有参考资料模型依然可能 “围绕资料自由发挥、断章取义、错误拼接”资料中没有的内容模型仍会编造答案存在 “RAG 中毒” 风险检索到事实正确但具有误导性的片段模型照单全收错误被 “有来源背书” 掩盖静态资料无法应对动态、实时、系统操作类需求RAG 本质是 “把已有文档塞给模型”—— 资料更新就要重新切片、重新向量化、重建索引无法获取实时数据、无法调用 API、无法查询业务数据库、无法执行计算或操作外部系统所有知识必须 “预先入库”无法按需动态获取—— 世界信息无限、向量库容量与更新频率有限形成根本性矛盾上下文窗口与 Token 成本的硬约束为了不漏检倾向于多召回 → 上下文越来越长 → Token 费用飙升、推理变慢、关键信息被 “淹没在中部”Lost in the Middle为了控成本少召回 → 关键资料没进来 → 答不准。RAG 始终在 “漏检” 与 “超限” 之间两难没有最优解。✅ 一句话RAG 解决了 “模型不知道的知识”但解决不了 “找不准知识”、“知识装不下”、“知识不会自动更新”、“需要动手操作” 这四大类问题。4、Context Engineering上下文工程理想化是“把文档切 chunk → embedding → vector search → LLM”但实际上“chunk切磋 → embedding 不准确→ 召回错误 →上下文污染 →LLM得到错误的信息”这也进一步说明并不是给大模型越多的资料它就越聪明检索到更多内容 ≠ 模型一定更聪明。上下文工程 系统化设计、组织、优化 “放进 Context 里的内容与结构”让模型在有限窗口里高效、准确、低成本地产出好答案。Context Engineering 不是放弃检索而是系统化管理 “放进上下文里的内容”筛选、排序、压缩、结构化分区、摘要去重、动态截断、对话历史精简。目标是 “在有限窗口里放最有价值、最不容易混淆的信息”。它不只是 “写一句提示词”也不只是 “多塞点资料”而是决定 “放什么、不放什么、怎么排序、怎么分组、怎么压缩、怎么拼接、怎么复用历史” 的整套工程方法。以下是AI总结的内容这一阶段暴露出的新问题权威文献总结出四大失效模式全部指向 “光靠整理上下文永远跨不过去的天花板”1上下文中毒Context Poisoning一旦错误或过时信息被纳入上下文模型会把它当作事实继续推理、层层叠加、越错越远不会自我纠正。整理得再好错误来源依然是错误答案2上下文溢出与注意力崩塌Context Bloat Lost in Middle无论怎么压缩、精简窗口始终有上限。资料越长、轮次越多 → 模型注意力越分散 → 中部内容基本 “看不见” → 同时 Token 成本呈非线性增长。这是 Transformer 架构的物理特性不是工程优化能根治的3被动资料无法变成主动能力Context Engineering 依然在做 “把资料提前准备好塞进去”—— 资料必须预先存在、被检索到、且塞得下。遇到以下场景无论上下文整理得多完美依然无能为力需要实时数据股价、天气、最新政策→ 不可能全量预存需要查询业务数据库 / 调用 API → 不可能把全库每次都塞进上下文需要计算、代码、系统操作 → 上下文里只有文字模型 “看得到但做不到”问题需要 “先查 A→再用 A 查 B→再算 C” 多步闭环 → 一次性上下文塞不下整条推理链4上下文管理复杂度爆炸为了维持效果需要维护向量库、分块策略、重排模型、摘要逻辑、对话记忆、版本更新……整个系统越来越复杂、依赖链越来越长、排查越来越难5、Function Calling/Tool Use假设用户提问现在东京天气怎么样模型再聪明也不能只靠自身参数获得实时天气信息它需要能够访问天气查询工具来获取实时天气这就需要让模型“能动手”即LLM不需要自己完成所有事情他可以决定什么时候使用外部工具。模型不把世界知识全塞进上下文而是生成结构化调用指令 → 交给外部系统执行 → 拿到结果再回答。本质是不把 “答案素材” 塞给模型而是把 “获取素材的能力” 交给模型。Function Calling函数调用定义大模型按照你的函数描述与参数规范自动判断 “要不要调用、调用哪个、参数怎么填”直接输出结构化调用指令JSON 格式由程序去执行真实代码 / 接口拿到结果后再交回模型整理回答。Function Calling核心功能是统一格式规范描述但是本身标准不统一不同大厂的API定义不一样Function Calling对System Prompt中自然语言描述的内容进行了标准化。比如每个Tool都用一个JSON对象来定义工具名写在name字段功能说明写在desc字段参数写在Params等。然后这些JSON也从System Prompt中剥离出来单独放到一个字段里。同时也规定了AI使用工具时应该返回的格式。Tool Use工具使用定义比 Function Calling 范围更广的统称 ——把任何外部能力搜索、数据库、代码解释器、API、计算器、RAG 检索都当作 “工具”让模型自主选择、组合、调用、结果复盘、多轮联动。Function Calling 是实现 Tool Use 最核心的底层机制。这一阶段暴露出来的问题①工具选择错误②参数错误即使schema定义清楚模型仍可能生成非法参数③多步工具调用不稳定单次调用可以但连续调用多个工具根据中间结果决策时容易失败④胶水代码多每个工具都要开发者手动接入缺乏统一标准。6、四阶段对比总结PromptRAGContextFunction calling7、Agent定义Agent 大模型 Function Calling/Tool Use 自主决策循环 记忆 / 状态管理提问题ai给的仅仅是答案或者怎么做最终还是要自己动手。为此新的想法出现让AI自己动手做最早出现的是AutoGPT。AutoGPT本质并没有重新发明一个新的GPT模型它做的是GPT4自主循环任务分解工具记忆。举例来说比如写好一些函数把这些函数以及它们的功能描述、使用方法注册到AutoGPT中AutoGPT会根据这些信息生成一个System Prompt告诉AI模型 用户给了你哪些工具都是干什么的以及AI使用它们应该返回什么样的格式最后把这个System Prompt连同用户的请求发送给AI模型。行业也是由此大规模意识到真正的Agetn不一定需要更大的模型也可以通过“模型Loop”获得新的能力。人们把AutoGPT这种负责在模型、工具和最终用户之间传话的程序叫做AI Agent。AI Agent是一个运行在本地的小程序负责在用户、AI模型和功能函数之间的传话。比如想让AI帮忙管理本地文件但模型本身无法直接读取硬盘这就需要提前写好文件处理函数并注册到AgentAgent告诉Ai模型Ai模型就可以返回指令引导Agent调用相应函数完成用户请求。这些提供给AI调用的函数或者服务就叫做Agent Tool。这一阶段暴露的问题Agent 最大问题不是“不会做”而是“不稳定”。Agent 阶段的痛点本质不是 “模型不会调用”而是 “调用太分散、对接太重复、治理太混乱”——Function Calling 解决了 “模型怎么发请求”但完全不解决 “系统之间怎么对接”。MCP 不是替代 Function Calling而是把 Function Calling 从 “应用里硬编码的零散代码” 升级为 “标准化、可复用、可治理、跨模型” 的完整基础设施层—— 模型依然用 Function Calling 做决策MCP 负责把决策统一路由到任意后端。边界清晰Function Calling 模型 “怎么说”MCP 系统 “怎么通”两者配合才是生产环境 Agent 的完整架构。一句话总结LLMFC 是 Agent 的 “核心大脑 双手”但真正让它成为 Agent 的是包裹在 LLMFC 外面那层「自主决策循环 状态记忆」—— 缺了这一层就只是 “能调用工具的问答接口”称不上 Agent。8、MCPModel Context Protocol模型上下文协议定义MCP简单来说就是一个通信协议用来规范Agent和Tool服务之间的交互。MCP只负责帮Agent管理工具、资源和提示词并不关心用了什么AI模型。当用户提出问题后Agent会先从MCP Server中收集所有可用的工具信息再把这些工具转化为AI模型能够理解格式和用户请求一起发送给AI。运行Tool的服务叫做MCP Server调用它的叫做MCP Client除了Tool这种普通的函数调用方式MCP Server也可以直接提供数据或者提示词模版。MCP加入后Agent执行任务的流程大致如下仅参考①用户提出问题明天天气怎么样Agent把问题包装到UserPrompt中 ②Agent通过MCP协议从MCP Server中获取所有Tool的信息 ③AI Agent会把这些信息或者转化为System Prompt或者Function Calling的格式然后和User Prompt一起打包发送给AI模型 ④Ai模型发现有一个叫web_browse的网页浏览工具于是通过普通回复或者Function Calling格式产生一个调用这个Tool 的请求希望去网上搜索答案 ⑤Agent收到请求后通过MCP协议去调用MCP Server里的web_browse工具web_browse访问指定网站后将内容返还给Agent ⑥Agent转发给Ai模型 ⑦Ai模型根据网页内容和自己的头脑风暴生成最终答案 ⑧最后由Agent把结果展示给用户9、25 AI Concepts如图所示还有25个需要知道的概念但是由于是英文 资料还未整理先暂存一下后续整理出来了再继续写。