一文掌握Agent八股

前言本文主要讲解了一些Agent猫股涉及Agent的概念Tools;Planning;Memory;Agent的范式及范式之间的选择策略;Workflow与Agent。;MCP skill RAG(召回率)Agent概念Agent LLM 大脑 Tool 工具调用 Memory 记忆 Planning 规划调度LLM 大脑负责理解、推理生成自然语言结构化计划。Tools感官和四肢负责搜索、代码执行、API 调用等。Planning拥有多步推理、自我纠错功能。Memory短期上下文记忆 长期持久知识记忆保证会话的连贯及个性化偏好。更部分组件Tools工具是给大模型外接的可被调用的能力接口提前定义好名称、功能描述、入参格式、出参结构。本质是把现实能力标准化、函数化让 LLM 看得懂、会调用。比如联网搜索、代码执行、文件读写、数据库查询、API 接口、计算器等都属于 Agent 工具。工具与模型如何交互模型决策LLM 理解用户需求后判断是否需要调用工具、调用哪个工具、传什么参数。格式输出模型按约定格式输出工具调用命令函数名加参数。框架调度Agent 解析指令触发对应工具执行。结果回传把工具执行结果再返回给 LLM。二次推理LLM 结合工具返回结果再整理答案继续规划下一步动作形成闭环。Planning模型仅能单点问答难以处理复杂模糊的多步骤任务。而大模型 Agent 具备规划拆解、多步推理及自我纠错能力可将复杂大目标拆分成有序子任务并依据工具执行结果动态调整。推理技术实现推理技术常见有两种CoT思维链(a) 核心让模型分步输出推理过程而非直接给出答案大幅提升复杂问题推理效果。(b) 特点纯内部思考无工具调用无分支无回溯。© 适用场景适合逻辑链条清晰、步骤可枚举的问题如数学应用题、逻辑推理、代码调试等。(d) 局限一旦中间某一步推理出错后续步骤会沿着错误方向继续累积且模型无法回头修正同时由于不借助外部工具遇到需要实时信息或精确计算的任务时容易出错。ToT思维树(a) 核心在推理节点衍生多条思考分支评估筛选最优路径推进适配复杂决策场景但计算成本更高。(b) 特点全局探索可回溯适用于多找多种解法的难题。© 适用场景适合开放性强、存在多条可行路径的问题如创意写作、策略规划、数学证明的多种解法探索等。(d) 局限由于需要同时维护和评估多条分支计算开销显著增大且分支评估本身依赖模型的判断能力若评估标准不清晰反而可能引入更多噪声。可以把CoT理解成「⼀条路⾛到底」ToT理解成「⾛到岔路⼝先看看⼏条路选最好的那条再往前」规划模式在推理技术的基础上Agent 的规划在实际运作中有两种主流模式先规划后执行Plan and Execute 模式提前生成完整任务步骤结构清晰便于人工审核。但应变性差中间结果异常时原有计划易失效。边执行边规划ReAct 模式单步执行后实时决策下一步灵活性强。但易陷入局部最优解偏离整体目标。工程实践中常融合两种模式先制定整体粗略规划把控方向执行阶段再动态微调。MemoryAgent 引入记忆机制一般分为短期会话记忆和长期持久知识记忆短期会话记忆保存当前会话上下文保证会话连贯交互。长期持久知识记忆存储用户偏好、历史任务、业务知识。不用每次重复交代背景复用过往结果减少重复提问或重复执行让 Agent 更懂用户。Agent范式ReAct范式ReAct Reasoning推理 Action行动是边执行边规划的闭环范式。推理与行动交替循环直到任务完成。核心三步循环Reasoning → Acting → Observation思考ReasoningLLM 基于上下文做推理明确下一步要做什么。行动Action根据上一步推理结果调用工具与外部环境交互。观察Observation接受工具返回的结果作为新输出进入下一轮推理。这三个步骤不断循环重复直到任务完成或触发终止条件。优缺点优势减少幻觉。复杂任务成功率高。推理轨迹清晰可解释可调试。局限多轮循环导致延迟升高效率低。效果依赖工具质量与稳定性。缺少全局思维是局部贪心策略容易陷入死胡同迷失问题。总结适合做动态、实时性强的任务。Plan-and-Execute范式Plan and Execute先规划后执行先由 LLM 生成完整步骤清单再按顺序执行。优势结构清晰便于人工审核整体目标明确。局限灵活性差。中间结果异常时计划易失败需要重新规划。总结适合做步骤明确的长期复杂任务。Reflection范式Reflection反思是 Agent 自我纠错与迭代优化能力的体现。Agent 完成子任务或整个任务后进行反思即再调用一次 LLM 来判断任务执行过程和结果是否符合预期。如果不符合则重试或执行其他策略。Reflection 通常不单独使用而是作为增强层叠加在 ReAct 和 Plan and Execute 上。优势显著降低错误率提升鲁棒性输出更可靠。局限增加 LLM 调用次数带来额外延迟与成本。关系通常作为增强模块。如何抉择实时交互、动态不确定、需要随时查资料 / 调⼯具 → 选 ReAct流程固定、⻓链路复杂任务、需要可控可审核 → 选 Plan-and-Execute对结果正确率要求⾼、允许增加成本、需要⾃我纠错 → 叠加 Reflection在实际应用中也可以将它们结合起来(a) 用 Plan and Execute 做整体规划。(b) 每个步骤内部用 React 来执行。© 关键步骤再加上 Reflection 做质量把关。WorkFlow与Agent定义 Workflow即工作流全链路If-else 固定分支固定接口调用无大模型自主决策。它完全由规则驱动完全由人来设计每个节点如何执行。Agentic WorkFlow智能体工作流通过前⽂的内容我们⼤概可以感受到 Agent 在很⼤程度上仍然是⼀个⿊盒⾃由度很⾼LLM 来做推理和决策⽽在现实中的企业级的业务应⽤极少有这样的存在因为纯 Agent 系统可控性差、成本⽆法预估、出现问题难以排查处理⽽纯 Workflow 系统 ⽆法理解多样化的情景或语境因此也有局限性。因此 Agentic Workflow 诞⽣了成为了业界主流⽅案Agentic Workflow 是上层的编排框架把Agent、LLM、Tools 组织成⼀条确定性流程每个节点做什么、按什么顺序流转都是开发者设计写好的⻣架 固定 Workflow可控、可运维、可排查⾎⾁ 局部 Agent 能⼒LLM 推理、动态决策例如我们最常⻅的业务系统智能客服它就不是⼀个 纯 Agent 的系统⽽Workflow⽐如其完整业务链路⽤户提问→ 意图分类→ 分⽀路由订单问题 / 售后问题 / 账号问题→ 查业务数据订单、会员、权限→ 知识库检索→ 答案组装输出以上 整体流转、分⽀、先后顺序、依赖关系全是代码 / 配置写死的标准 Workflow。但在其中也融⼊了Agent的能⼒意图理解 问题归类 →【Agent 能⼒】传统⼯作流关键词匹配、正则、固定词库死板容易漏Agent 能⼒由 LLM ⾃主语义推理理解⼝语化、歧义、多意图、啰嗦话术动态判断⽤户真实诉求动态检索策略 ⽂档筛选 →【Agent 能⼒】流程规定「必须检索知识库」是固定流程但检索哪些知识库召回⼏⼗条⽂档哪些有⽤、哪些过滤是否需要多轮补充检索、扩写关键词这部分不靠硬编码 if/else靠 LLM 推理判断 → Agent ⾏动决策。业务结果 规则⽂档 融合⽣成回答 →【Agent 能⼒】流程固定必须拼接订单数据 平台规则但怎么改写话术、⼝语化、规避敏感词如何结合⽤户上下⽂做个性化回答哪些信息省略、哪些重点强调由 LLM ⾃主组织语⾔、逻辑整合 → ⽣成式 Agent 能⼒。异常兜底、反问澄清 →【Agent 能⼒】固定流程只会报错 / 固定话术Agent 可以⾃主判断问题信息不全主动反问⽤户补充信息动态调整后续流程⾛向。总结整体流转步骤顺序、核心分支、系统交互是 Workflow保证企业可控、好排查成本可控、不跑偏。在 Workflow 中的节点包括语义理解、意图推理、动态筛选、内容改写、模糊决策。灵活交互是 Agent 能力。Agentic Workflow 是固定流程框住边界在边界内让 LLM 做智能决策。这样既不让 AI 乱跳流程解决了纯 Agent 不可控的问题又让 AI 在关键环节具备理解和灵活能力解决了传统工作流太僵硬的问题。Single-Agent 与 Multi-AgentSingle agent 即单个 Agent 完成任务而 multi agent 是多个独立的 Agent 通过协作完成复杂任务。每个 Agent 专注于特定角色或技能类比人类的团队分工协作。Multi agent.背景单个Agent在完成复杂任务时任务的所有步骤都由同一个Agent完成可能会有以下几种情况任务太长信息量大上下文窗口容纳不下导致信息遗忘。不同步骤的专业领域不同单个Agent不够专精。任务中存在多个并行子任务但单个Agent只能串行执行。因此单个Agent无法很好地完成任务。实现两种核心架构模式Orchestrator-Subagent 模式主流⼀个编排 AgentOrchestrator 负责全局规划和任务分发多个⼦ AgentSubagent 并⾏或串⾏执⾏具体⼦任务最终由 Orchestrator 汇总输出。Peer-to-Peer 模式Agent 之间平等对话、相互审查适合需要辩论或验证的场景缺点无统一调度Agent间易出现分工混乱甚至出现任务重复或遗漏Agent 问题排查困难无全局调用记录出现错误时无法定位问题可控性差Agent间协商结果不可预知。效率不稳定Agent间意见分歧需反复协商。Function CallingFunction calling函数调用是大模型的工具调用能力可以理解为让大模型像程序员一样调用预设的函数工具来解决问题。它与普遍编程里的函数调用有核心区别普通编程中的函数调用由开发者硬编码指定程序就一定会执行这个函数。大模型的 Function calling由大模型通过识别意图自主决策调用哪个函数。具体运作流程如下(a) 预设信息我们先告诉模型有哪些可用函数提供每个函数的功能、参数及工具列表。(b) 意图识别大模型根据用户问题识别并判断出是否需要调用函数、调用哪个函数以及传什么参数。© 指令生成大模型不会直接调用这些函数而是生成一个函数调用指令。(d) 后端执行由后端程序解析该函数指令再去执行调用这个函数并拿到结果最后由框架封装好了会帮助我解析调用e函数调用结果传给大模型大模型生成最终回答弊端精准的函数定义与提示词设计性能损耗与响应延迟模型决策能力有限复杂场景难以覆盖安全性风险MCP没有 MCP 前使用 function calling 时需要定义工具将工具列表给到大模型但各家大模型的规范都不一样。所以MCP 的存在就是将规范统一依靠一套标准适配所有大模型。MCP模型上下文协议是一套标准化的通信协议加接入规范可以理解为一套统一的工具接入标准。有了 MCP 之后工具的开发者只需要按照 MCP 的规范开发一次工具这个工具就可以被所有大模型使用这就是 MCP 的由来。MCP靠“三层组件统一协议规范”实现跨模型标准化核心是屏蔽不同大模型的接口差异具体逻辑如下统⼀⼯具描述规范MCP 定义了标准化的⼯具注册格式要求所有⼯具必须包含「⼯具名称、功能描述、参数类型与约束、返回值格式、错误码」等固定字段。不管是知识库检索⼯具还是数据库查询⼯具都要按这套格式定义⼤模型和⼯具之间的 “沟通语⾔” 被统⼀。统⼀交互流程规范MCP 规定了「请求 - 调⽤ - 响应」的端到端标准化流程和具体⼤模型⽆关MCP Client嵌⼊⼤模型宿主接收⽤户请求后按 MCP 格式打包 “问题 ⼯具列表” 发给⼤模型⼤模型按 MCP 规范⽣成⼯具调⽤指令格式全⼀致不再区分 OpenAI/ClaudeMCP Client 解析指令调⽤ MCP Server 上的⼯具⼯具执⾏结果按 MCP 标准格式返回给⼤模型⽣成最终回答。三层组件解耦屏蔽模型差异MCP Server负责按 MCP 规范封装⼯具对外提供标准化接⼝和底层⼤模型完全解耦MCP Client作为中间层⼀头对接 MCP Host⼤模型应⽤⼀头对接 MCP Server核⼼作⽤是协议转换—— 把⼤模型的指令转成 MCP 标准格式也把⼯具结果转成⼤模型能识别的格式MCP Host运⾏⼤模型的应⽤如 ChatGPT 客户端、⾃定义 AI 助⼿只需内置 MCPClient就能⽆缝调⽤所有 MCP Server 上的⼯具不⽤关⼼⼯具的具体实现和模型差异。SKillSkill 的本质是大模型可调用的说明书。每个 Skill 定义了特定任务的执行规范。Skill 超越了传统提示词形成了结构化能力封装不仅描述“做什么”还规定“怎么做”支持示例引导和条件逻辑判断。如何创建和使用skill创建 skill 需要在指定目录下建立文件夹与文件具体要求如下路径与命名路径为用户目录下的 .cloud-skill。文件夹名称及 skill 名称必须与内部元数据一致。核心文件核心文件为 skill.md包含“元素”和“指令”两部分(a) 元素元数据定义 skill 的基本信息包含 name 和 description 两个关键词。其中name 必须与文件夹名称完全相同description 用于向模型描述该 skill 的用途。(b) 指令定义具体行为规范明确模型在执行任务时应遵守的格式与逻辑可加入输入输出示例帮助模型理解。Skill的基础工作流程用户发起请求后系统启动 3 阶段处理机制第一阶段Cloud Code 将所有 skill 的元数据发送给模型。模型仅看到各 skill 名称和描述判断当前请求是否匹配某个 skill。第二阶段模型识别匹配的 skill 并请求调用 Cloud Code。接收到响应后加载对应 skill 的完整内容读取 skill.md 中的全部指令。第三阶段模型依据详细指令生成结果。结果经由 Claude Code 返回给用户用户获得符合预期规范的输出。渐进式披露机制的核心设计第一层元数据层始终可见的目录索引包含所有 skill 的 name 和 description永久加载占用极小 token 开销。第二层指令层按需加载的行为规范仅当 skill 被选中时才加载其完整的 skill.md 内容避免无关指令污染上下文。第三层资源层条件触发的深层依赖包含 reference 引用文件和 script 脚本只有满足特定条件时才会加载或执行实现“按需中的按需”加载策略。高级功能之reference条件性知识注入Reference ⽤于引⼊外部参考⽂档如财务⼿册、法务条款等专业资料⽂件独⽴存放不直接写⼊ skill.md仅在相关场景下被动动态加载触发机制基于指令中的条件判断例如“当提及预算时读取集团财务⼿册”Cloud Code 在解析指令后判断是否需要加载若⽆相关内容则⽂件不会进⼊上下⽂Reference 加载会消耗 token因为其内容会被送⼊模型上下⽂供推理使⽤适合存储静态知识类信息实现精准的知识调⽤避免资源浪费高级功能之script自动化代码执行Script ⽀持运⾏本地脚本完成实际操作如上传⽂件、同步数据、调⽤ API 等在 skill.md 中声明触发条件与执⾏⽅法脚本执⾏不占⽤模型上下⽂Cloud Code 仅执⾏脚本并获取结果不读取代码内容⼏乎零 token 消耗安全性依赖于清晰的执⾏说明若未明确运⾏⽅法模型可能尝试阅读代码导致意外加载脚本内容⾄上下⽂建议在指令中详尽描述调⽤⽅式Reference与script的加载差异Reference 是读取型资源内容被加载进上下文参与推理Script 是执行资源仅运行脚本并返回结果不消耗 token不暴露代码。两者共同构成资源层的双轨机制实现知识与行动的能力分离提升系统效率与安全性。Agent Skill和MCP的核心区别MCP 的主要功能是连接外部数据源提供实时数据查询能力如订单状态、销售记录相当于为模型接入数据库接口。Agent skill 专注于数据处理规范规范模型如何使用数据完成特定任务。官方定位MCP 连接数据skill 教会使用数据。两者如何选择轻量级任务优先使用 Agent Skill如格式化输出、简单脚本执行、本地自动化。数据密集型或高安全要求场景选择 MCP如企业级 API 对接、敏感数据访问控制、更强的安全隔离与权限管理。RAGRAG检索增强生成一句话理解让大模型在回答前先去查一份外部知识库查到的内容会整合到 prompt 提示词中再输入给大模型。RAG 是先将知识作为向量存储到向量数据库再将用户输入的提示词与向量数据库中的知识向量进行相似度匹配检索出相关的片段最后将检索出来的内容与用户提示词一起发送给大模型生成最终回答。背景RAG 用来解决三件事有了 RAG 答案更准解决知识过时通过检索外部知识库融入最新最准确的信息提高回答的可靠性。减少模型幻觉基于真实检索结果生成内容避免输出无根据或错误信息。使用内部私有化数据。RAG流程检索检索在向量数据库中检索与问题相关的信息。向量知识库收集数据收集与问答系统相关的数据可来自文档、网页、数据库等。数据清洗对收集到的数据进行清洗去除噪声、重复项和无关信息确保数据的质量。知识库构建将清洗后的数据构建成知识库通常将文档按照一定策略切块如固定大小、语义分块等。使用Embedding 模型将这些片段转成向量并将这些向量存储在向量数据库中。如何检索问题向量化当用户输入查询问题时。使用Embedding模型将问题转化成问题向量相似度检索在向量数据库中检索与问题向量最相似的知识库片段这通常通过计算向量之间的相似度来实现。结果排序根据相似度得分对检索到的结果进行排序选择最相关的片段作为后续生成的输入。增强通过增强步骤LLM模型能够充分利用外部知识库的信息增强可以理解为将检索到的性相关片段与原始问题合并形成更丰富的上下文信息。总结RAG 的“检索、增强、⽣成”从哪⾥检索增强了什么谁⽣成了答案是从外部知识库中检索到的相关的知识增强了 提示词prompt将检索到的相关⽚段与原始问题合并形成更丰富的上下⽂信息⼤模型 拿着增强后的 Prompt ⽣成了问题答案。RAG的优势提升回答质量通过检索外部知识库融入最新最准确信息提高回答的可靠性。减少模型幻觉基于真实检索结果生成内容避免输出无根据或错误信息。缺点依赖知识库质量及系统设计系统回答的效果与外部知识库质量和整体系统设计有较大关系若设计不合理会导致答案偏差。系统复杂度增加大规模的知识库检索会让整体系统更加复杂增加计算开销并且会延长系统响应时间。召回率召回率指的是在所有真正相关的文档中有多少被成功地检索出来。计算方式召回率等于检索到的相关内容数量%所有相关内容的总数量。在 RAG 中召回率尤为关键因为大模型能不能答对很大程度上取决于有没有拿到相关信息。召回率越高生成答案时能参考的有效信息就越多回答质量和准确性越好。RAG 工程落地计算流程构造测试数据集question 加人工标注相关 chunk 列表。每条问题走检索流程得到召回 chunk 列表。逐题统计召回率。计算平均召回率。