从零到一学 AI Agent梳理核心概念、工具交互与知识增强大模型提示词AgentAgent定义Agent核心组成Agent 与工作流的区别Agent 的核心机制与工作范式Agent 的常见局限与应对方法ToolTool核心定义Tool 的核心作用Tool 的关键要素与类型Tool 四大关键要素Tool 常见类型查询类工具只读写入类工具有副作用执行类工具高风险AI 辅助类工具Function Calling核心组成MCP传统 C/S 与 MCP C/S 的区别三大角色SkillSkill定义Skill组成Skill的核心价值Function Calling、MCP、Skill 三者关系Skill 渐进式披露Rag知识库知识库定义知识库的作用向量数据库向量定义为什么不用普通数据库向量数据库定义向量数据库与普通数据库对比常见主流向量数据库RAG 两大核心阶段RAG 完整四步工作流程RAG 与 Function Calling、MCP、Skill 的层级关系完整运行链路RAG 底层向量运行链路技术原理视角Agent 完整运行链路业务高层视角有 RAG 和没有 RAG 的核心差异HarnessHarness定义为什么必须要有 HarnessHarness 的核心环节本文将带你从零到一系统性梳理 AI Agent 的完整知识体系。我们会从大模型与提示词基础出发讲清 Agent 的核心定义、组成与运行逻辑接着深入拆解 Tool、Function Calling、MCP、Skill 构成的工具交互体系最后解析向量数据库与 RAG 检索增强的底层原理帮你一次性建立完整、自洽的 AI Agent 知识框架。大模型大模型是知识面很广、能思考推理、能生成内容的超级助手大在哪参数量大、训练数据大Token 就是大模型处理文字的最小基本单位可以是一个字、一个词、一个字母或标点大模型只认识 Token不直接认识文字。大模型的本质是一个 Next-Token 预测机器根据上下文预测下一个 Token大模型不能直接识别文字先把文字切分成Token词元再转为数字向量依靠Token完成理解、计算和文字生成上下文窗口本质就是可处理的Token最大数量。缺点无执行能力只会说、不会做无法与外部交互上下文窗口有限处理大文件时读前忘后记不住长内容知识有截止时间仅懂训练截止日前的内容不懂最新资讯易幻觉编造不懂也会编造假事实、假数据提示词User Prompt用户提示词要做到目标明确、背景充足、输出要求清晰这样才能让大模型给出你想要的结果减少 “幻觉” 和无效回答。System Prompt系统提示词的三大核心用途是为模型设定角色身份、定义行为规则、约束输出格式。身份设定给模型一个明确的角色定位比如 “你是资深软件测试工程师” 或 “你是小学老师”。这决定了它的回答语气、专业度和思考方式。行为规则定义模型的边界告诉它 “能做什么、不能做什么”。例如 “只能回答软件测试相关问题不回答与业务无关的闲聊”避免它跑偏或胡编乱造。输出格式约束强制模型按固定格式输出比如 Markdown 列表、JSON、表格等。这能让回答更规整方便后续处理或阅读。写好 Prompt 的 6 个核心原则是给模型角色、用正向约束、补充背景信息、指定输出格式、提供 Few-shot 示例、引导模型用思维链CoT思考以此减少幻觉、稳定输出、提升结果质量。给模型设定角色明确模型身份如 “资深工程师”让它的回答更专业同时缩小思考范围。优先正向约束而非负向禁止与其说 “不要啰嗦”不如说 “控制在 3 句话以内”指令更明确结果也更稳定。提供充足的背景信息把业务、系统、场景等必要信息都给全减少模型的猜测降低幻觉概率。指定输出格式Agent 开发关键提前约定格式如 JSON、Markdown方便后续程序解析避免输出混乱。Few-shot 示例引导直接给模型 3 个左右的 “输入→输出” 样例比写一堆规则更直观、有效。引导模型 “先思考再回答”思维链 CoT让模型分步拆解问题、写出思考过程逻辑更连贯出错率更低。大模型本身的能力是固定的但它的表现好坏完全取决于你怎么 “激活” 它。Prompt 就是你和它沟通的 “钥匙”写得越精准它的能力就发挥得越充分。当下普通大模型仅局限于文字对话交互只能给出回答和思路建议无法自主拆解步骤、调用能力、落地执行复杂任务很多场景下只能被动应答不能真正帮人解决实际问题。而智能 Agent 的出现正好弥补了这一短板。AgentAgent定义Agent 是由大模型驱动的智能系统它的核心作用就是解决传统大模型只能单次问答、无法自主执行复杂任务的短板。通过自主规划、调用工具、动态调整执行路径让大模型从单纯的聊天应答升级为能独立完成多步骤任务的智能体。Agent 的本质就是让大模型在循环中不断根据新信息做决策、调工具直到任务完成。Agent核心组成Agent 是由大模型决策大脑、工具执行双手、记忆信息存储与「思考 - 行动 - 观察 - 再思考」的执行循环构成的智能体。大模型LLM大脑整个 Agent 的决策核心负责理解任务、分析状态、推理并决定下一步该做什么。所有的 “思考” 和判断都由它完成。工具Tools双手让 Agent 能与外部世界交互的执行单元比如查数据库、搜引擎、读写文件、调用 API 等。大模型发指令工具负责执行再把结果返回给模型。记忆Memory记事本负责记录信息是串联多步骤任务的关键短期记忆对话历史、工具返回结果存在上下文窗口里长期记忆跨会话的持久信息存在外部数据库中执行循环Loop节拍器Agent 的核心引擎也是它和普通大模型调用的根本区别。通过「思考→行动→观察→再思考」的闭环不断迭代直到任务完成。Agent 的核心价值在于融合大模型的推理能力与工具的执行能力让系统能处理无法穷举所有情况的复杂任务。Agent 与工作流的区别工作流是固定规则、按预设流程跑Agent 是大模型自主思考、动态决策、能随机应变。对比维度Workflow工作流Agent 智能体决策核心固定硬编码规则大模型自主推理执行路径固定不变动态调整灵活性差遇异常易卡住强可临场应变适用场景步骤明确、重复性高的标准化任务目标开放、情况多变的复杂任务可预测性高流程结果可控低结果受模型影响成本低无大模型调用高依赖多轮 LLM 调用维护方式业务一变需改流程、改代码调整提示词或工具无需重构Agent 的核心机制与工作范式Agent 的所有复杂功能都建立在一个最基础的循环逻辑之上本质是一个「决策→执行→反馈→再决策」的闭环。核心四步流程调大模型让它决策接收用户任务由大模型根据当前上下文决定下一步要做什么调用什么工具、执行什么动作。判断是否完成大模型同时判断当前任务是否达成目标。如果完成就退出循环如果没完成继续执行。没完成就执行工具把结果追加进 messages根据决策结果调用工具如 API、数据库、搜索引擎并将工具返回的结果追加到消息列表上下文中。带着新结果再调大模型进入下一轮大模型结合上一轮的工具结果重新决策进入下一轮循环。简单来说Agent 的本质就是让大模型在循环中不断根据新信息做决策、调工具直到任务完成。基于这个基础循环衍生出了三种常见的工作范式ReActReasoning推理 Acting行动交替范式核心逻辑Thought思考→ Action行动→ Observation观察 循环执行走一步看一步边推理边执行。特点不提前制定完整计划每一步的行动都依赖上一步的结果反馈能灵活处理不确定的复杂任务适合步骤少、目标模糊、需要随机应变的场景如对话式问题排查、实时信息查询、轻量故障处理。Plan-and-Execute规划 - 执行范式核心逻辑一个「规划 - 执行 - 评估 - 调整」的持续闭环它会先通过大模型制定一份清晰、可拆解的全局执行计划将复杂目标分解为一系列可落地的子任务随后按计划依次执行子任务并根据工具反馈与环境变化动态评估执行效果、调整后续计划不断迭代优化直至目标完成。特点先定全局路线再分步执行适合流程相对固定、目标明确的长任务可控性强。Reflection反思 / 复盘范式核心逻辑在执行完成后加入「评估 - 反思 - 修正」环节通过自我检查、复盘错误再重新执行不断优化结果质量。特点通过 “质量飞轮” 持续迭代能大幅降低错误率适合对结果质量要求高的场景如代码生成、写作。对比表格对比维度ReActPlan-and-ExecuteReflection决策时机每一步实时决策开始前一次性规划执行后延迟决策对结果做二次判断全局视野弱只看当前这步强提前看到任务全貌中基于完整执行结果做复盘视野随迭代扩大灵活性强可随时根据结果调整方向弱计划一旦生成调整成本较高中调整成本集中在反思环节需重新执行适合任务步骤少3步以内的简单任务多5步以上的复杂长任务不限适合单轮/多轮执行的所有任务尤其高质量要求场景Token消耗随步骤数线性增长后期成本高规划阶段集中消耗执行阶段可控每轮反思会额外消耗一次模型调用总token与迭代次数成正比实现难度低结构简单易上手中需管理计划状态与重规划逻辑中需设计评估规则、反思prompt和修正逻辑ReAct 是 “边走边想的探险家”解决动态不确定的问题Plan-and-Execute 是 “先定路线再出发的工程师”解决长流程、可规划的问题Reflection 是 “做完复盘再优化的学习者”解决结果质量提升的问题。Agent 的常见局限与应对方法名称核心问题应对方法幻觉传导第一步错误假设后续步骤被放大一步错、步步错工具调用结果增加可验证逻辑高风险操作加入人工确认环节工具调用失败工具超时、格式异常、权限不足导致流程卡死或走偏在 System Prompt 中明确错误格式和处理方式增加重试、降级策略成本和速度多轮 LLM 调用导致 Token 消耗大、响应时延高设置最大循环次数上限能用 Workflow 实现的固定流程优先用 Workflow降低 Agent 调用频次循环风险陷入无效循环如查 A→查 B→又查 A无法判断任务何时结束设置最大迭代次数限制每一步增加 “信息是否足够” 的判断逻辑明确终止条件Tool前面我们讲过Agent 依靠「决策→执行→反馈→再决策」闭环运行。大模型只负责思考和决策但本身没有实际执行能力不能联网、调用接口、操作本地文件。想要把决策真正落地、完成复杂任务就必须依赖Tool工具承担所有执行环节。Tool核心定义在 Agent 开发中Tool 是专门提供给 Agent 调用的外部功能模块是承接大模型决策、完成实际操作的执行载体。从宏观结构来看一个完整的 Tool 由两大部分组成执行逻辑大模型看不到真正负责干活的代码、接口或程序用来完成实际动作比如联网搜索、发起接口请求、读写本地文件、查询数据库等。描述信息相当于给大模型看的工具说明书告诉大模型这个工具是做什么的、适用什么场景、需要传入什么参数让大模型知道什么时候调用、怎么正确调用。Tool 的核心作用补齐大模型能力短板大模型有知识和思考能力但不能联网查实时信息、不能操作系统、不能调用第三方服务Tool 刚好弥补这些局限。支撑 Agent 决策执行闭环Agent 靠大模型做决策靠 Tool 做执行决策之后调用工具、拿到结果再反馈给大模型形成完整循环实现自主完成任务。拆解复杂任务分工协作复杂任务可以拆成多个小环节每个环节对应一个专用 ToolAgent 按需组合调用不同工具就能一步步完成多步骤复杂工作。Tool 的关键要素与类型Tool 四大关键要素前面我们把 Tool 分成执行逻辑、描述信息两大部分落到实际开发标准格式里会细化成四个核心要素刚好对应组成一个可被大模型识别调用的标准工具函数本体就是前面说的执行逻辑是工具真正运行、完成业务操作的代码核心。这部分是实现具体功能的代码比如查数据库、发通知、联网搜索都由它来完成。它有一个关键特点大模型本身看不到这段代码也不关心它的内部实现只负责决定调用哪个工具、传什么参数。name工具名称工具唯一标识大模型通过这个名字精准定位、调用对应的工具。description 功能描述给大模型看的说明文字写清楚工具用途、适用场景是大模型判断「要不要用、什么时候用」的关键。parameters 参数定义规定工具需要哪些输入、参数类型、是否必填、参数含义引导大模型生成合法正确的调用参数避免调用失败。很多人会好奇大模型本身不直接运行代码也看不到工具的实现细节它怎么知道有哪些工具可用、什么时候该调用、该传什么参数在开发中Agent 会在每次对话开始前把所有可用工具的 name名称、description描述和parameters参数定义也就是 Tool 四要素里的这三项打包成一个列表工具清单通过 API 的 tools参数传给大模型。大模型每次做决策时都会读取这份工具清单判断当前任务需要什么操作、调用哪一个工具以及该传入什么参数。Tool 常见类型根据工具的功能特点和对外部环境的影响我们可以把 Tool 分为四类风险等级依次递增直接决定了工具能否被 Agent 自主调用、是否需要人工确认。查询类工具只读这类工具的核心特点是只读取数据不改变任何状态。常见场景查天气、搜索网页、读取文件、查询数据库记录等。操作前后文件、数据库都不会发生任何变化。风险等级低说明这类工具可以放心让 Agent 自主调用出错了顶多拿到无效数据不会产生不可逆的后果。写入类工具有副作用这类工具会修改系统状态且部分操作不可逆。常见场景往数据库插入记录、发送通知消息、发邮件、更新配置等。比如发出去的通知收不回来写入数据库的记录删除后也会留下痕迹。风险等级中说明对高风险的写入操作比如批量发通知、修改线上配置建议增加人工确认步骤不建议让 Agent 完全自主执行。执行类工具高风险这类工具可以直接操作系统底层影响范围和破坏性最大。常见场景执行 shell 命令、运行脚本、重启服务、部署代码等。一条错误的 shell 命令可能删掉整个目录一次错误部署可能导致线上服务中断。风险等级高说明使用这类工具必须做到两点一是严格限制权限范围比如只允许执行白名单内的命令二是重要操作必须经过人工审批绝对不能让 Agent 自主决策。AI 辅助类工具这类工具是把其他 AI 能力封装成可调用的模块本身不直接操作系统。常见场景给 Agent 配置 RAG 检索工具让它随时查询内部知识库、历史故障案例或者把专门的分类模型封装成工具让 Agent 调用它对日志做分类只拿结论无需自己处理细节。风险等级低到中说明操作本身不会改变外部系统状态风险主要集中在检索结果的质量和子模型的可靠性上。设计 Agent 系统时每个工具的风险等级直接决定了两件事它能不能被自主调用需不需要人工确认这是保证 Agent 安全可靠运行的基本原则一定要在开发阶段就提前规划好。工具类型核心特点典型场景风险等级安全建议查询类只读仅读取数据不改变任何系统状态查天气、搜索网页、读取文件低可放心让 Agent 自主调用无需人工确认写入类有副作用会修改数据 / 状态部分操作不可逆数据库写入、发送通知、发邮件中关键写入操作如批量通知、线上配置修改建议增加人工确认步骤执行类高风险直接操作系统底层破坏性强执行 Shell 命令、重启服务高1. 严格限制权限如白名单命令2. 所有重要操作必须人工审批禁止自主执行AI 辅助类封装其他 AI 能力不直接操作外部系统RAG 知识库检索、日志分类低 - 中重点关注子模型 / 检索结果的可靠性控制输入范围Function Calling了解了 Tool 的构成而支撑大模型调用这些 Tool 的底层能力就是Function Calling函数调用。Function Calling 是大模型的一项核心能力它能让大模型根据用户需求主动判断并调用提前定义好的外部工具也就是前面讲的 Tool以此获取信息或执行操作而不是只能停留在纯文本对话。本质上它是大模型与 Agent 系统之间的标准化通信协议定义了工具调用的统一指令格式让大模型的决策能被 Agent 精准解析和执行从而实现与外部工具的间接交互。你可以把它理解成大模型的「指令翻译器」你提前给大模型喂了所有 Tool 的 name、description、parameters也就是工具清单用户问了一个需要联网 / 查数据才能回答的问题大模型通过 Function Calling 能力判断出 “我需要调用哪个工具、该传什么参数”并生成标准的工具调用指令你的 Agent 系统拿到指令后去执行工具再把结果返回给大模型大模型基于工具返回的结果整理出最终答案回复给用户。它的核心作用就是让大模型从 “只会聊天”变成 “能主动使用工具解决问题”这也是所有 Agent 能跑起来的底层基础。它和 Tool、Agent 的关系Tool是你写好的、能干活的具体功能比如搜索、查天气Function Calling是大模型调用这些 Tool 的 “能力” 和 “标准协议”Agent是基于大模型 Function Calling Tool 搭建起来的完整系统。没有 Function Calling大模型就不知道该怎么调用你写的 Tool举例用户问“今天北京天气怎么样”你提前给大模型定义了一个 get_weather 工具说明它的用途是 “查询指定城市的天气”参数是 city大模型通过 Function Calling 能力判断需要调用 get_weather工具并生成调用指令{“name”: “get_weather”, “parameters”: {“city”: “北京”}}系统执行这个工具拿到 “晴25℃” 的结果返回给大模型大模型基于结果回复用户“今天北京天气晴气温 25℃。”核心组成一次完整的 Function Calling 工具调用流程由三部分构成三者缺一不可工具定义Function Definition也就是给大模型的「工具说明书」是大模型判断是否调用、如何调用工具的核心依据。包含工具名称、功能描述、参数格式和前面讲解的 Tool 关键要素完全对应。工具调用请求Function Call Request大模型结合用户问题和已有的工具定义自动生成标准化调用指令。以结构化 JSON 格式输出明确指定要调用的工具名称和所需传入的参数值相当于大模型下发的执行指令。工具执行与结果返回Function Execution ResponseAgent 系统接收调用指令后运行提前编写好的工具业务逻辑函数本体执行完成后将返回结果做格式化处理再回传给大模型。大模型依据工具返回内容整理最终回答或进入下一轮决策循环。整体流程可以简单概括为开发者下发工具定义 → 大模型生成工具调用请求 → 系统执行工具并返回结果 → 大模型基于结果继续处理任务。Agent 标准执行闭环流程用户提问 → Agent 打包「需求 工具清单」发给大模型 → 大模型决策并生成 Function Calling 指令 → Agent 解析指令并执行工具 → 工具结果回传大模型 → 大模型判断下一步 → 循环执行直到任务完成 → Agent 反馈最终结果给用户接收用户提问用户输入需求、问题或任务指令进入 Agent 系统。打包上下文发送给大模型Agent 会把用户的原始需求以及提前定义好的工具清单一起打包发送给大模型。大模型思考决策触发 Function Calling大模型理解用户意图结合工具清单判断能不能直接回答还是必须调用工具。如果需要联网、查数据或执行操作就通过 Function Calling 生成标准化的工具调用请求JSON 格式。Agent 解析指令并执行工具Agent 系统解析大模型发来的调用信息识别要调用的工具和参数运行对应的工具底层函数本体完成实际操作搜索、查库、读写文件、调用接口等。工具结果回传大模型把工具执行拿到的结果整理格式化后重新发给大模型。大模型判断下一步大模型根据工具返回的真实数据重新评估任务状态是可以直接整理答案回复用户还是需要继续调用其他工具循环执行直到任务完成如果任务还没完成就会重复「决策→调用工具→结果回传」的闭环直到所有必要操作完成大模型生成最终答案。Agent 反馈最终结果Agent 将大模型整理好的最终答案以自然语言的形式反馈给用户整个流程结束。Function Calling 虽然能让单款大模型顺利调用工具但它属于厂商私有规范不同大模型的调用格式不统一工具无法跨模型复用。为了解决这个痛点行业推出了一套跨模型通用开放标准协议——MCP。MCPMCPModel Context Protocol模型上下文协议是由 Anthropic 推出的跨模型开放标准协议用来统一「大模型 ↔ 各种工具 / 数据源」的交互方式目标是让工具 “一次开发所有模型都能用”像 AI 世界的Type-C 接口。为了实现跨模型通用工具交互MCP 整体采用了客户端 - 服务器C/S架构。但这里的 C/S 架构和我们传统客户端 - 服务器并不完全相同。传统 C/S 与 MCP C/S 的区别传统客户端 - 服务器架构面向人与应用交互客户端是用户操作入口服务端提供业务数据与服务。而 MCP 的客户端 - 服务器架构面向大模型与工具交互不再以人为直接访问主体而是通过 Client 做协议中转、Server 承载工具能力核心是实现模型与工具解耦、跨模型复用、安全权限隔离。维度传统C/S架构MCP 的C/S架构核心目标面向人机交互客户端是用户操作入口服务器提供数据与业务服务面向程序间通信解耦大模型与工具实现工具“一次开发多模型复用”客户端是「协议翻译官」服务端是「工具容器」谁是“用户”人通过客户端桌面/移动 APP直接操作大模型/Agent客户端是为程序服务的中间层不直接面向用户分工重点服务器处理核心业务逻辑与数据存储客户端负责界面渲染与用户交互服务器仅按 MCP 标准暴露工具接口不关心调用方是哪个模型客户端负责将模型请求转为 MCP 协议、再将工具结果转为模型可理解的格式部署方式服务器为集中式远程服务客户端为用户设备上的专用程序MCP Server 可本地或远程部署与模型/Agent 完全解耦Client 运行在 HostAI 应用/Agent内部三大角色为了实现这种通用、可复用的工具交互MCP 定义了一套清晰的客户端 - 服务器架构其中包含三大核心角色MCP Host主机 / 宿主就是用户直接交互的 AI 应用比如 Claude Desktop、VS Code AI 插件或是你自己开发的 Agent 程序。它是整个流程的起点内置了 MCP Client负责管理和协调所有客户端与服务器的连接。MCP Client客户端运行在 Host 内部的协议组件是 Host 和 Server 之间的 “翻译官”。每个 Client 对应一个 Server负责按 MCP 协议格式收发消息、处理会话和权限把大模型的调用请求转换成 MCP 指令再把工具返回的结果回传给模型。MCP Server服务器独立部署的、提供具体能力的程序比如数据库查询、文件操作、网络搜索等工具。它只需要按 MCP 标准对外暴露接口就能被任何支持 MCP 的 Host 调用真正实现 “一次开发多模型复用”。用户在 Host 里提问 → 内置的 Client 按 MCP 协议向 Server 发请求 → Server 执行工具并返回结果 → Client 再把结果交给 Host 里的大模型处理。有了 Function Calling 解决单模型工具调用再加上 MCP 解决工具跨模型复用大模型已经能稳定调用各类工具了。但在真实的业务场景中用户的需求很少是 “调用某个单一工具”而是一连串需要多工具配合的完整流程。为了让大模型能直接应对这类场景我们需要对工具进行更高一层的场景化封装 —— 这就是 Skill技能。Skill前面说了 Function Calling 如何让单模型调用工具也说了 MCP 如何让工具跨模型复用。但当面对复杂业务场景时零散的工具调用依然存在明显短板如果每次处理相同场景都要从零规划工具调用顺序、重复说明流程规则不仅沟通成本极高也容易出错。为了把成熟的业务流程沉淀下来让大模型可以一键调用完整的场景化能力我们需要对工具进行更高一层的封装 —— 这就是 Skill技能。Skill定义在 AI Agent 体系中Skill技能 是面向特定业务场景对工具、流程、规则与指令进行聚合封装后形成的一套完整、可复用的能力单元。它不是简单地把多个 Tool 打包在一起而是为了解决一个具体业务问题把 “需要哪些工具、按什么顺序调用、参数怎么传递、结果怎么处理、有哪些规则约束” 全部沉淀下来让大模型可以直接调用一整套成熟的业务流程不用每次从零开始规划。Skill组成一个完整的 Skill通常由 4 个核心部分组成组成部分核心作用通俗理解技能元信息定义技能的身份与适用场景包括名称、描述、触发条件告诉 Agent“我是做什么的什么时候该叫我干活”关联工具集完成任务所需的所有底层能力包括通过 MCP 对接的外部工具、自定义脚本、模板文件干活需要用到的 “工具包”执行编排逻辑预设工具调用的先后顺序、分支判断、参数传递规则定义完整工作流写好的 “操作说明书”规定第一步干啥、第二步干啥业务规则与指令给大模型的任务说明、输出格式要求、边界约束以及异常兜底策略任务的 “质量标准” 和 “应急预案”Skill的核心价值站在开发者和Agent 运行两个视角Skill 的核心价值降低开发者重复配置成本把固定业务流程、工具调用规则、提示指令一次性封装进 Skill开发者不用每次搭建对话、设计流程都重复定义一遍。减少大模型自主规划的流程错误预设好工具调用顺序、参数传递逻辑与分支规则不用让大模型从零即兴规划流程避免步骤错乱、参数传错、漏调用工具等问题。实现业务能力复用一套成熟 Skill 可以跨多个 Agent、多个业务场景直接复用不用重复开发同款业务逻辑。能力集中管理、维护更简单业务规则、工具关联、输出约束全部收敛在 Skill 内部后续只需修改一处所有引用该 Skill 的场景同步生效不用逐个地方改配置。Function Calling、MCP、Skill 三者关系Function Calling、MCP、Skill 三者形成由底层到上层的完整架构层级Function Calling 是大模型调用工具的底层基础能力解决模型能不能主动调用外部能力的问题MCP 是工具互联互通的标准化协议依托 Function Calling 能力实现工具一次开发、多模型跨场景复用Skill 则是在 MCP 标准化工具之上面向业务场景做流程、规则、多工具编排的高层封装把零散工具沉淀为可复用的完整业务技能。三者逐层依赖、逐层封装共同构成 AI Agent 工具调用与业务能力落地的完整体系。Skill 渐进式披露虽然 Skill 解决了流程封装的问题但新的挑战随之而来如果把所有 Skill 的完整信息一次性全塞给大模型不仅会让上下文 Token 瞬间膨胀还会导致大模型因技能过多而出现匹配混乱、误调用的问题。为了解决这个矛盾就有了 Skill 渐进式披露 的设计思路不把所有 Skill 的全部信息一次性暴露给大模型而是按需、分阶段地开放。在实际实现中它有两种非常经典的设计方式方式一按加载粒度分层Token 优化方案从技术实现的角度把一个 Skill 的完整信息拆成三层只在真正需要时才加载对应部分元数据MetadataAgent 启动时仅加载所有 Skill 的 name 和 description让 Agent 知道 “我有哪些技能”但只占极少 Token完整指令正文当用户需求触发相关 Skill 时才把该 Skill 的完整流程、指令加载进上下文附属资源脚本、模板、参考文档等仅在执行过程中真正需要时才读取。这种设计能把绝大多数 Token 消耗推迟到真正需要的时候避免上下文被大量无关信息 “撑爆”。方式二按业务场景 / 权限分层安全管控方案从业务安全与效率的角度根据 Skill 的使用场景和权限等级控制它们对大模型的可见范围基础层通用必备技能闲聊、帮助启动时永久披露始终可用场景层业务场景技能办公、出行识别到场景后动态披露用完可回收敏感层高权限操作删除、支付用户授权 / 校验后才披露防止误操作。RagRAG Retrieval-Augmented Generation检索增强生成简单来说大模型的训练知识有时间截止也无法知晓我们私有的文档、业务资料、内部知识库RAG 的核心作用就是先从私有知识库检索相关内容再把检索到的资料喂给大模型让模型依据真实文档作答有效解决知识滞后、无法使用私有数据、模型幻觉瞎编等问题。知识库在 RAG 里要给大模型补充外部知识首先得有一个存放这些知识的 “容器”—— 这就是知识库。知识库定义它是经过整理、清洗的资料集合比如产品文档、FAQ、技术手册、行业规范、内部流程等。这些内容会被统一管理成为大模型可以参考的权威事实依据。知识库的作用解决大模型 “知识过时、不懂业务、容易幻觉” 的问题。让回答有事实依据不是模型瞎编。知识库不是一个简单的文档存储工具它是连接静态文档和动态AI应用的桥梁是整个AI应用体系的基础设施。但有了知识库还不够如果只用关键词匹配很容易漏掉语义相近但字面不同的内容效率低、不准。要实现 “语义级快速检索”就需要把知识转成向量再用专门的数据库来管理也就是向量数据库。向量数据库向量定义在 AI 领域文本、图片、音频等都属于非结构化数据计算机无法直接理解。通过Embedding 模型可以把这类数据转换成一串固定长度的高维数字数组这串数字就是向量。向量的每一个维度都承载着对应数据的语义或特征信息文本向量承载语句的语义含义行人 / 图像向量承载外观、轮廓、身形等视觉特征为什么不用普通数据库MySQL 等传统关系型数据库擅长精准匹配适合结构化数据的等值查询、条件筛选。但高维向量有两个关键特点维度极高通常几百到上千维业务需要的不是完全相等而是相似度匹配。如果用普通数据库存储向量只能逐条暴力计算相似度数据量大时检索速度极慢完全无法满足 RAG、行人重识别等线上业务的秒级响应需求。向量数据库定义向量数据库是专门面向高维向量设计用于存储、索引、管理海量向量并提供高速相似度检索的专用数据库。核心核心能力就三点安全海量存储高维向量构建专用向量索引优化检索效率输入查询向量快速召回库中相似度最高的 Top-K 结果。向量数据库与普通数据库对比向量数据库之所以能实现 “又快又准” 的检索核心秘密就是 ANN 索引Approximate Nearest Neighbor近似最近邻索引。它是一种专门为高维向量设计的检索算法通过提前对海量向量进行聚类、分层、建图构建出一张能快速导航的 “地图”。速度快的核心传统数据库面对海量高维向量只能逐条暴力计算相似度检索效率极低而 ANN 索引让检索时无需遍历全量数据只需在相近的小范围里做匹配计算量大幅减少从而实现亿级数据下的毫秒级召回。我们常说的 HNSW、IVF 等算法都是 ANN 索引的主流实现。结果准的核心它跳出了传统关键词字面匹配的局限借助高维 Embedding 向量承载文本语义或图像细粒度特征再通过余弦相似度、欧氏距离等专业度量方式计算向量间的相似程度能够精准识别语义相近、特征相似的内容让检索结果更贴合用户真实意图。常见主流向量数据库轻量入门首选Chroma特点Python 原生的本地轻量级向量数据库几乎零配置几行代码就能跑通完整流程是新手学习、快速验证 RAG 原型的最低摩擦选择。适合场景本地开发、功能验证、学习跑 Demo。局限不支持高可用、分布式部署不适合直接上生产环境。高性能检索引擎FAISS特点Meta 开源的向量检索引擎专注于高性能向量相似度计算检索速度极快常作为核心组件搭配自定义数据存储使用。适合场景需要嵌入到现有项目中做本地或小规模向量检索的场景。局限本身不提供完整的数据库服务需要自己额外处理数据存储、持久化等逻辑。工业级私有化方案Milvus特点开源的工业级向量数据库功能最全面支持多种索引类型、分布式部署与数据持久化社区活跃、文档完善。适合场景数据必须内网部署、需要精细控制、规模较大的企业级生产环境。局限部署与运维复杂度较高学习曲线比轻量工具更陡。高性能低资源方案Qdrant特点基于 Rust 实现的高性能向量数据库内存占用低、查询速度快接口设计简洁支持 HTTP/gRPC。适合场景对性能和资源消耗敏感的生产环境比如在有限硬件上跑大规模高并发检索。多模态友好方案Weaviate特点开源向量数据库内置 Embedding 模型集成支持直接处理文本、图片、音频等多模态数据无需自己单独调用模型生成向量。适合场景需要多模态检索或希望简化 Embedding 处理步骤的场景。全托管云服务Pinecone特点全托管的云向量数据库无需管理服务器、扩容、备份等基础设施开箱即用只需调用 API 即可。适合场景小团队 / 创业公司快速上线 RAG 服务不想投入专职运维人员。局限数据存储在第三方存在合规顾虑按用量收费大规模使用成本较高。RAG 两大核心阶段RAG 的整个工作流程可划分为离线预处理数据准备和在线推理问答生成两个核心阶段。一、第一阶段离线预处理索引构建阶段也叫入库阶段、准备阶段特点提前做、一次性 / 定时做用户提问时不参与核心动作收集私有文档PDF、Word、笔记、业务手册、网页文档等文本切片分块Chunk 拆分对每个文本块做 Embedding 向量化将向量与原文存入向量数据库核心目的把非结构化文档变成可被语义检索的向量索引为 RAG 提前备好可用的知识库。二、第二阶段在线推理检索生成阶段也叫问答阶段 / 实时交互阶段特点用户一问立刻实时执行核心动作核心目的用户提问时临时检索私有资料让模型照着真实文档回答解决 “瞎编、不懂业务、知识过时” 的问题。用户输入问题召回问题做 Embedding 向量化去向量库语义检索捞出相似度最高的文档片段重排对召回结果做二次筛选选出最相关的片段生成把「检索到的原文 用户问题」一起拼接近 Prompt大模型基于真实资料生成答案RAG 完整四步工作流程在两大阶段基础上可细化为标准四步执行流程文档预处理将 PDF、笔记、业务文档等进行文本切分、向量化存入向量数据库检索Retrieval用户发起提问时从向量库中匹配捞出最相关的文档片段增强Augmented把检索到的真实资料拼接进提示词作为模型回答的依据生成Generation大模型参考给定的专业资料输出准确、有据可依的答案。RAG 与 Function Calling、MCP、Skill 的层级关系Function Calling大模型底层基础能力让模型具备主动识别意图、主动调用外部能力的能力MCP工具标准化协议统一各类外部能力的接入规范RAG一种专门用于私有知识库检索的特殊工具能力Skill在 MCP 标准化工具之上把 RAG、其他业务工具、执行流程、业务规则统一编排封装形成完整可复用的业务场景能力。完整运行链路下面我们从「底层技术」和「业务应用」两个视角分别还原一次完整的问答过程RAG 底层向量运行链路技术原理视角前面我们了解了知识库、向量数据库的分工这里用一段链路讲清 RAG 内部的核心逻辑知识库输出原始文本内容由 Embedding 模型将文本转为语义向量让机器理解文本语义向量数据库存储向量并构建 ANN 索引实现快速检索用户问题同样转为向量在向量库中检索相似内容召回原始文档片段喂给大模型生成答案Agent 完整运行链路业务高层视角用户提出专业知识类问题大模型通过 Function Calling 判断需要检索内部资料调用经过 MCP 标准化封装的 RAG 工具从私有知识库检索匹配相关文档片段交由 Skill 统一编排问答逻辑、输出格式与约束规则最终给出贴合业务、有据可查、低幻觉的回答有 RAG 和没有 RAG 的核心差异对比维度没有 RAG 的 Agent / 大模型有 RAG 的 Agent / 大模型知识来源仅依赖模型训练阶段的静态知识存在时间截止模型静态知识 私有 / 最新知识库双来源私有数据支持无法访问企业内部文档、业务手册等私有数据可直接调用私有知识库回答完全贴合业务场景回答准确性对专业 / 业务问题容易出现幻觉、编造数据回答以真实文档为依据可溯源幻觉大幅降低知识更新成本极高只能通过重新训练 / 微调模型更新知识极低只需更新知识库文档模型回答同步生效定制化难度高依赖模型微调成本高、周期长低维护知识库即可快速实现业务定制合规与私有化难以满足输出内容不可控数据完全私有可控更容易满足合规要求典型应用场景通用闲聊、创意生成、公开常识问答企业内部问答、客服知识库、文档助手、专业顾问前面我们已经了解了 RAG、向量数据库、函数调用、Skill 技能、MCP 协议等各类能力组件。但这些零散的能力本身并不能自动变成一个完整可运行的 AI Agent。大模型只负责思考和生成指令各类工具只负责单一功能执行中间缺少一套统一调度、流程控制、状态管理、任务编排的工程层来把它们串联起来。而承担这一串联、调度、管控角色的核心概念就是 Harness。HarnessHarness定义在 AI Agent 领域有一个核心公式Agent 大模型 Model HarnessModel大模型只负责思考、推理、生成指令是 Agent 的大脑只会输出文本和决策意图不会主动调用工具、不会管理流程、不会维护状态。Harness可以理解为智能驾驭层 / 工程调度骨架是大模型以外所有用来串联、调度、管控、执行的整套工程系统。通俗比喻大模型是司机只会思考往哪走、做什么决策Harness 是车身 方向盘 控制系统 交通规则负责帮司机控车、认路、遵守规则、处理突发情况让决策真正落地执行。为什么必须要有 Harness如果只有大模型没有 Harness模型想调用工具没有逻辑帮它解析参数、发起调用多步任务没法自动循环只能一问一答没有记忆和状态记不住上下文、任务进度没有安全限制容易越权、乱调用、无限循环RAG、Skill、MCP、函数调用这些能力散落各处无法联动。Harness 的核心作用把大模型的 “想法”变成能落地的 “行动”。Harness 的核心环节要把 “只会聊天的裸模型” 变成 “能干活的 Agent”Harness 的工作可以拆成 6 个核心环节它们从输入到输出完整覆盖了 Agent 运行的全流程上下文精细化解决的问题模型这一轮该看到什么信息负责处理输入信息比如 RAG 召回的知识、工具返回的结果、对话历史通过过滤、摘要、排序等方式给模型提供精简且关键的上下文避免信息过载。工具系统解决的问题模型可以用哪些能力执行操作统一管理 Function Calling、Skill 技能、RAG 知识库、第三方 API 等所有能力组件为模型提供可调用的 “工具库”让它的指令能真正转化为实际操作。执行编排解决的问题模型下一步该如何推进任务驱动「思考 → 决策 → 调用工具 → 观察结果 → 再思考」的闭环循环控制多步骤任务的推进节奏让 Agent 能自主完成复杂任务而不是只能一问一答。记忆与状态解决的问题模型跨轮次需要保留哪些状态维护会话历史、任务进度、用户偏好、临时数据等状态信息让 Agent 能记住对话上下文、任务进度实现连贯对话和长任务执行。评估与观测解决的问题如何判断模型的执行效果与状态给 Agent 的执行加上 “可观测性”记录调用日志、任务链路、错误信息同时通过结果校验、目标评估判断任务是否完成让问题可追溯、可复盘。约束与恢复解决的问题如何在出错时保障系统稳定并恢复运行为 Agent 加上安全护栏与异常处理机制比如权限控制、调用次数限制、敏感操作拦截同时处理工具调用失败、超时、死循环等异常让 Agent 即使出错也能安全兜底、继续运行。
从零到一学 AI Agent：梳理核心概念、工具交互与知识增强
从零到一学 AI Agent梳理核心概念、工具交互与知识增强大模型提示词AgentAgent定义Agent核心组成Agent 与工作流的区别Agent 的核心机制与工作范式Agent 的常见局限与应对方法ToolTool核心定义Tool 的核心作用Tool 的关键要素与类型Tool 四大关键要素Tool 常见类型查询类工具只读写入类工具有副作用执行类工具高风险AI 辅助类工具Function Calling核心组成MCP传统 C/S 与 MCP C/S 的区别三大角色SkillSkill定义Skill组成Skill的核心价值Function Calling、MCP、Skill 三者关系Skill 渐进式披露Rag知识库知识库定义知识库的作用向量数据库向量定义为什么不用普通数据库向量数据库定义向量数据库与普通数据库对比常见主流向量数据库RAG 两大核心阶段RAG 完整四步工作流程RAG 与 Function Calling、MCP、Skill 的层级关系完整运行链路RAG 底层向量运行链路技术原理视角Agent 完整运行链路业务高层视角有 RAG 和没有 RAG 的核心差异HarnessHarness定义为什么必须要有 HarnessHarness 的核心环节本文将带你从零到一系统性梳理 AI Agent 的完整知识体系。我们会从大模型与提示词基础出发讲清 Agent 的核心定义、组成与运行逻辑接着深入拆解 Tool、Function Calling、MCP、Skill 构成的工具交互体系最后解析向量数据库与 RAG 检索增强的底层原理帮你一次性建立完整、自洽的 AI Agent 知识框架。大模型大模型是知识面很广、能思考推理、能生成内容的超级助手大在哪参数量大、训练数据大Token 就是大模型处理文字的最小基本单位可以是一个字、一个词、一个字母或标点大模型只认识 Token不直接认识文字。大模型的本质是一个 Next-Token 预测机器根据上下文预测下一个 Token大模型不能直接识别文字先把文字切分成Token词元再转为数字向量依靠Token完成理解、计算和文字生成上下文窗口本质就是可处理的Token最大数量。缺点无执行能力只会说、不会做无法与外部交互上下文窗口有限处理大文件时读前忘后记不住长内容知识有截止时间仅懂训练截止日前的内容不懂最新资讯易幻觉编造不懂也会编造假事实、假数据提示词User Prompt用户提示词要做到目标明确、背景充足、输出要求清晰这样才能让大模型给出你想要的结果减少 “幻觉” 和无效回答。System Prompt系统提示词的三大核心用途是为模型设定角色身份、定义行为规则、约束输出格式。身份设定给模型一个明确的角色定位比如 “你是资深软件测试工程师” 或 “你是小学老师”。这决定了它的回答语气、专业度和思考方式。行为规则定义模型的边界告诉它 “能做什么、不能做什么”。例如 “只能回答软件测试相关问题不回答与业务无关的闲聊”避免它跑偏或胡编乱造。输出格式约束强制模型按固定格式输出比如 Markdown 列表、JSON、表格等。这能让回答更规整方便后续处理或阅读。写好 Prompt 的 6 个核心原则是给模型角色、用正向约束、补充背景信息、指定输出格式、提供 Few-shot 示例、引导模型用思维链CoT思考以此减少幻觉、稳定输出、提升结果质量。给模型设定角色明确模型身份如 “资深工程师”让它的回答更专业同时缩小思考范围。优先正向约束而非负向禁止与其说 “不要啰嗦”不如说 “控制在 3 句话以内”指令更明确结果也更稳定。提供充足的背景信息把业务、系统、场景等必要信息都给全减少模型的猜测降低幻觉概率。指定输出格式Agent 开发关键提前约定格式如 JSON、Markdown方便后续程序解析避免输出混乱。Few-shot 示例引导直接给模型 3 个左右的 “输入→输出” 样例比写一堆规则更直观、有效。引导模型 “先思考再回答”思维链 CoT让模型分步拆解问题、写出思考过程逻辑更连贯出错率更低。大模型本身的能力是固定的但它的表现好坏完全取决于你怎么 “激活” 它。Prompt 就是你和它沟通的 “钥匙”写得越精准它的能力就发挥得越充分。当下普通大模型仅局限于文字对话交互只能给出回答和思路建议无法自主拆解步骤、调用能力、落地执行复杂任务很多场景下只能被动应答不能真正帮人解决实际问题。而智能 Agent 的出现正好弥补了这一短板。AgentAgent定义Agent 是由大模型驱动的智能系统它的核心作用就是解决传统大模型只能单次问答、无法自主执行复杂任务的短板。通过自主规划、调用工具、动态调整执行路径让大模型从单纯的聊天应答升级为能独立完成多步骤任务的智能体。Agent 的本质就是让大模型在循环中不断根据新信息做决策、调工具直到任务完成。Agent核心组成Agent 是由大模型决策大脑、工具执行双手、记忆信息存储与「思考 - 行动 - 观察 - 再思考」的执行循环构成的智能体。大模型LLM大脑整个 Agent 的决策核心负责理解任务、分析状态、推理并决定下一步该做什么。所有的 “思考” 和判断都由它完成。工具Tools双手让 Agent 能与外部世界交互的执行单元比如查数据库、搜引擎、读写文件、调用 API 等。大模型发指令工具负责执行再把结果返回给模型。记忆Memory记事本负责记录信息是串联多步骤任务的关键短期记忆对话历史、工具返回结果存在上下文窗口里长期记忆跨会话的持久信息存在外部数据库中执行循环Loop节拍器Agent 的核心引擎也是它和普通大模型调用的根本区别。通过「思考→行动→观察→再思考」的闭环不断迭代直到任务完成。Agent 的核心价值在于融合大模型的推理能力与工具的执行能力让系统能处理无法穷举所有情况的复杂任务。Agent 与工作流的区别工作流是固定规则、按预设流程跑Agent 是大模型自主思考、动态决策、能随机应变。对比维度Workflow工作流Agent 智能体决策核心固定硬编码规则大模型自主推理执行路径固定不变动态调整灵活性差遇异常易卡住强可临场应变适用场景步骤明确、重复性高的标准化任务目标开放、情况多变的复杂任务可预测性高流程结果可控低结果受模型影响成本低无大模型调用高依赖多轮 LLM 调用维护方式业务一变需改流程、改代码调整提示词或工具无需重构Agent 的核心机制与工作范式Agent 的所有复杂功能都建立在一个最基础的循环逻辑之上本质是一个「决策→执行→反馈→再决策」的闭环。核心四步流程调大模型让它决策接收用户任务由大模型根据当前上下文决定下一步要做什么调用什么工具、执行什么动作。判断是否完成大模型同时判断当前任务是否达成目标。如果完成就退出循环如果没完成继续执行。没完成就执行工具把结果追加进 messages根据决策结果调用工具如 API、数据库、搜索引擎并将工具返回的结果追加到消息列表上下文中。带着新结果再调大模型进入下一轮大模型结合上一轮的工具结果重新决策进入下一轮循环。简单来说Agent 的本质就是让大模型在循环中不断根据新信息做决策、调工具直到任务完成。基于这个基础循环衍生出了三种常见的工作范式ReActReasoning推理 Acting行动交替范式核心逻辑Thought思考→ Action行动→ Observation观察 循环执行走一步看一步边推理边执行。特点不提前制定完整计划每一步的行动都依赖上一步的结果反馈能灵活处理不确定的复杂任务适合步骤少、目标模糊、需要随机应变的场景如对话式问题排查、实时信息查询、轻量故障处理。Plan-and-Execute规划 - 执行范式核心逻辑一个「规划 - 执行 - 评估 - 调整」的持续闭环它会先通过大模型制定一份清晰、可拆解的全局执行计划将复杂目标分解为一系列可落地的子任务随后按计划依次执行子任务并根据工具反馈与环境变化动态评估执行效果、调整后续计划不断迭代优化直至目标完成。特点先定全局路线再分步执行适合流程相对固定、目标明确的长任务可控性强。Reflection反思 / 复盘范式核心逻辑在执行完成后加入「评估 - 反思 - 修正」环节通过自我检查、复盘错误再重新执行不断优化结果质量。特点通过 “质量飞轮” 持续迭代能大幅降低错误率适合对结果质量要求高的场景如代码生成、写作。对比表格对比维度ReActPlan-and-ExecuteReflection决策时机每一步实时决策开始前一次性规划执行后延迟决策对结果做二次判断全局视野弱只看当前这步强提前看到任务全貌中基于完整执行结果做复盘视野随迭代扩大灵活性强可随时根据结果调整方向弱计划一旦生成调整成本较高中调整成本集中在反思环节需重新执行适合任务步骤少3步以内的简单任务多5步以上的复杂长任务不限适合单轮/多轮执行的所有任务尤其高质量要求场景Token消耗随步骤数线性增长后期成本高规划阶段集中消耗执行阶段可控每轮反思会额外消耗一次模型调用总token与迭代次数成正比实现难度低结构简单易上手中需管理计划状态与重规划逻辑中需设计评估规则、反思prompt和修正逻辑ReAct 是 “边走边想的探险家”解决动态不确定的问题Plan-and-Execute 是 “先定路线再出发的工程师”解决长流程、可规划的问题Reflection 是 “做完复盘再优化的学习者”解决结果质量提升的问题。Agent 的常见局限与应对方法名称核心问题应对方法幻觉传导第一步错误假设后续步骤被放大一步错、步步错工具调用结果增加可验证逻辑高风险操作加入人工确认环节工具调用失败工具超时、格式异常、权限不足导致流程卡死或走偏在 System Prompt 中明确错误格式和处理方式增加重试、降级策略成本和速度多轮 LLM 调用导致 Token 消耗大、响应时延高设置最大循环次数上限能用 Workflow 实现的固定流程优先用 Workflow降低 Agent 调用频次循环风险陷入无效循环如查 A→查 B→又查 A无法判断任务何时结束设置最大迭代次数限制每一步增加 “信息是否足够” 的判断逻辑明确终止条件Tool前面我们讲过Agent 依靠「决策→执行→反馈→再决策」闭环运行。大模型只负责思考和决策但本身没有实际执行能力不能联网、调用接口、操作本地文件。想要把决策真正落地、完成复杂任务就必须依赖Tool工具承担所有执行环节。Tool核心定义在 Agent 开发中Tool 是专门提供给 Agent 调用的外部功能模块是承接大模型决策、完成实际操作的执行载体。从宏观结构来看一个完整的 Tool 由两大部分组成执行逻辑大模型看不到真正负责干活的代码、接口或程序用来完成实际动作比如联网搜索、发起接口请求、读写本地文件、查询数据库等。描述信息相当于给大模型看的工具说明书告诉大模型这个工具是做什么的、适用什么场景、需要传入什么参数让大模型知道什么时候调用、怎么正确调用。Tool 的核心作用补齐大模型能力短板大模型有知识和思考能力但不能联网查实时信息、不能操作系统、不能调用第三方服务Tool 刚好弥补这些局限。支撑 Agent 决策执行闭环Agent 靠大模型做决策靠 Tool 做执行决策之后调用工具、拿到结果再反馈给大模型形成完整循环实现自主完成任务。拆解复杂任务分工协作复杂任务可以拆成多个小环节每个环节对应一个专用 ToolAgent 按需组合调用不同工具就能一步步完成多步骤复杂工作。Tool 的关键要素与类型Tool 四大关键要素前面我们把 Tool 分成执行逻辑、描述信息两大部分落到实际开发标准格式里会细化成四个核心要素刚好对应组成一个可被大模型识别调用的标准工具函数本体就是前面说的执行逻辑是工具真正运行、完成业务操作的代码核心。这部分是实现具体功能的代码比如查数据库、发通知、联网搜索都由它来完成。它有一个关键特点大模型本身看不到这段代码也不关心它的内部实现只负责决定调用哪个工具、传什么参数。name工具名称工具唯一标识大模型通过这个名字精准定位、调用对应的工具。description 功能描述给大模型看的说明文字写清楚工具用途、适用场景是大模型判断「要不要用、什么时候用」的关键。parameters 参数定义规定工具需要哪些输入、参数类型、是否必填、参数含义引导大模型生成合法正确的调用参数避免调用失败。很多人会好奇大模型本身不直接运行代码也看不到工具的实现细节它怎么知道有哪些工具可用、什么时候该调用、该传什么参数在开发中Agent 会在每次对话开始前把所有可用工具的 name名称、description描述和parameters参数定义也就是 Tool 四要素里的这三项打包成一个列表工具清单通过 API 的 tools参数传给大模型。大模型每次做决策时都会读取这份工具清单判断当前任务需要什么操作、调用哪一个工具以及该传入什么参数。Tool 常见类型根据工具的功能特点和对外部环境的影响我们可以把 Tool 分为四类风险等级依次递增直接决定了工具能否被 Agent 自主调用、是否需要人工确认。查询类工具只读这类工具的核心特点是只读取数据不改变任何状态。常见场景查天气、搜索网页、读取文件、查询数据库记录等。操作前后文件、数据库都不会发生任何变化。风险等级低说明这类工具可以放心让 Agent 自主调用出错了顶多拿到无效数据不会产生不可逆的后果。写入类工具有副作用这类工具会修改系统状态且部分操作不可逆。常见场景往数据库插入记录、发送通知消息、发邮件、更新配置等。比如发出去的通知收不回来写入数据库的记录删除后也会留下痕迹。风险等级中说明对高风险的写入操作比如批量发通知、修改线上配置建议增加人工确认步骤不建议让 Agent 完全自主执行。执行类工具高风险这类工具可以直接操作系统底层影响范围和破坏性最大。常见场景执行 shell 命令、运行脚本、重启服务、部署代码等。一条错误的 shell 命令可能删掉整个目录一次错误部署可能导致线上服务中断。风险等级高说明使用这类工具必须做到两点一是严格限制权限范围比如只允许执行白名单内的命令二是重要操作必须经过人工审批绝对不能让 Agent 自主决策。AI 辅助类工具这类工具是把其他 AI 能力封装成可调用的模块本身不直接操作系统。常见场景给 Agent 配置 RAG 检索工具让它随时查询内部知识库、历史故障案例或者把专门的分类模型封装成工具让 Agent 调用它对日志做分类只拿结论无需自己处理细节。风险等级低到中说明操作本身不会改变外部系统状态风险主要集中在检索结果的质量和子模型的可靠性上。设计 Agent 系统时每个工具的风险等级直接决定了两件事它能不能被自主调用需不需要人工确认这是保证 Agent 安全可靠运行的基本原则一定要在开发阶段就提前规划好。工具类型核心特点典型场景风险等级安全建议查询类只读仅读取数据不改变任何系统状态查天气、搜索网页、读取文件低可放心让 Agent 自主调用无需人工确认写入类有副作用会修改数据 / 状态部分操作不可逆数据库写入、发送通知、发邮件中关键写入操作如批量通知、线上配置修改建议增加人工确认步骤执行类高风险直接操作系统底层破坏性强执行 Shell 命令、重启服务高1. 严格限制权限如白名单命令2. 所有重要操作必须人工审批禁止自主执行AI 辅助类封装其他 AI 能力不直接操作外部系统RAG 知识库检索、日志分类低 - 中重点关注子模型 / 检索结果的可靠性控制输入范围Function Calling了解了 Tool 的构成而支撑大模型调用这些 Tool 的底层能力就是Function Calling函数调用。Function Calling 是大模型的一项核心能力它能让大模型根据用户需求主动判断并调用提前定义好的外部工具也就是前面讲的 Tool以此获取信息或执行操作而不是只能停留在纯文本对话。本质上它是大模型与 Agent 系统之间的标准化通信协议定义了工具调用的统一指令格式让大模型的决策能被 Agent 精准解析和执行从而实现与外部工具的间接交互。你可以把它理解成大模型的「指令翻译器」你提前给大模型喂了所有 Tool 的 name、description、parameters也就是工具清单用户问了一个需要联网 / 查数据才能回答的问题大模型通过 Function Calling 能力判断出 “我需要调用哪个工具、该传什么参数”并生成标准的工具调用指令你的 Agent 系统拿到指令后去执行工具再把结果返回给大模型大模型基于工具返回的结果整理出最终答案回复给用户。它的核心作用就是让大模型从 “只会聊天”变成 “能主动使用工具解决问题”这也是所有 Agent 能跑起来的底层基础。它和 Tool、Agent 的关系Tool是你写好的、能干活的具体功能比如搜索、查天气Function Calling是大模型调用这些 Tool 的 “能力” 和 “标准协议”Agent是基于大模型 Function Calling Tool 搭建起来的完整系统。没有 Function Calling大模型就不知道该怎么调用你写的 Tool举例用户问“今天北京天气怎么样”你提前给大模型定义了一个 get_weather 工具说明它的用途是 “查询指定城市的天气”参数是 city大模型通过 Function Calling 能力判断需要调用 get_weather工具并生成调用指令{“name”: “get_weather”, “parameters”: {“city”: “北京”}}系统执行这个工具拿到 “晴25℃” 的结果返回给大模型大模型基于结果回复用户“今天北京天气晴气温 25℃。”核心组成一次完整的 Function Calling 工具调用流程由三部分构成三者缺一不可工具定义Function Definition也就是给大模型的「工具说明书」是大模型判断是否调用、如何调用工具的核心依据。包含工具名称、功能描述、参数格式和前面讲解的 Tool 关键要素完全对应。工具调用请求Function Call Request大模型结合用户问题和已有的工具定义自动生成标准化调用指令。以结构化 JSON 格式输出明确指定要调用的工具名称和所需传入的参数值相当于大模型下发的执行指令。工具执行与结果返回Function Execution ResponseAgent 系统接收调用指令后运行提前编写好的工具业务逻辑函数本体执行完成后将返回结果做格式化处理再回传给大模型。大模型依据工具返回内容整理最终回答或进入下一轮决策循环。整体流程可以简单概括为开发者下发工具定义 → 大模型生成工具调用请求 → 系统执行工具并返回结果 → 大模型基于结果继续处理任务。Agent 标准执行闭环流程用户提问 → Agent 打包「需求 工具清单」发给大模型 → 大模型决策并生成 Function Calling 指令 → Agent 解析指令并执行工具 → 工具结果回传大模型 → 大模型判断下一步 → 循环执行直到任务完成 → Agent 反馈最终结果给用户接收用户提问用户输入需求、问题或任务指令进入 Agent 系统。打包上下文发送给大模型Agent 会把用户的原始需求以及提前定义好的工具清单一起打包发送给大模型。大模型思考决策触发 Function Calling大模型理解用户意图结合工具清单判断能不能直接回答还是必须调用工具。如果需要联网、查数据或执行操作就通过 Function Calling 生成标准化的工具调用请求JSON 格式。Agent 解析指令并执行工具Agent 系统解析大模型发来的调用信息识别要调用的工具和参数运行对应的工具底层函数本体完成实际操作搜索、查库、读写文件、调用接口等。工具结果回传大模型把工具执行拿到的结果整理格式化后重新发给大模型。大模型判断下一步大模型根据工具返回的真实数据重新评估任务状态是可以直接整理答案回复用户还是需要继续调用其他工具循环执行直到任务完成如果任务还没完成就会重复「决策→调用工具→结果回传」的闭环直到所有必要操作完成大模型生成最终答案。Agent 反馈最终结果Agent 将大模型整理好的最终答案以自然语言的形式反馈给用户整个流程结束。Function Calling 虽然能让单款大模型顺利调用工具但它属于厂商私有规范不同大模型的调用格式不统一工具无法跨模型复用。为了解决这个痛点行业推出了一套跨模型通用开放标准协议——MCP。MCPMCPModel Context Protocol模型上下文协议是由 Anthropic 推出的跨模型开放标准协议用来统一「大模型 ↔ 各种工具 / 数据源」的交互方式目标是让工具 “一次开发所有模型都能用”像 AI 世界的Type-C 接口。为了实现跨模型通用工具交互MCP 整体采用了客户端 - 服务器C/S架构。但这里的 C/S 架构和我们传统客户端 - 服务器并不完全相同。传统 C/S 与 MCP C/S 的区别传统客户端 - 服务器架构面向人与应用交互客户端是用户操作入口服务端提供业务数据与服务。而 MCP 的客户端 - 服务器架构面向大模型与工具交互不再以人为直接访问主体而是通过 Client 做协议中转、Server 承载工具能力核心是实现模型与工具解耦、跨模型复用、安全权限隔离。维度传统C/S架构MCP 的C/S架构核心目标面向人机交互客户端是用户操作入口服务器提供数据与业务服务面向程序间通信解耦大模型与工具实现工具“一次开发多模型复用”客户端是「协议翻译官」服务端是「工具容器」谁是“用户”人通过客户端桌面/移动 APP直接操作大模型/Agent客户端是为程序服务的中间层不直接面向用户分工重点服务器处理核心业务逻辑与数据存储客户端负责界面渲染与用户交互服务器仅按 MCP 标准暴露工具接口不关心调用方是哪个模型客户端负责将模型请求转为 MCP 协议、再将工具结果转为模型可理解的格式部署方式服务器为集中式远程服务客户端为用户设备上的专用程序MCP Server 可本地或远程部署与模型/Agent 完全解耦Client 运行在 HostAI 应用/Agent内部三大角色为了实现这种通用、可复用的工具交互MCP 定义了一套清晰的客户端 - 服务器架构其中包含三大核心角色MCP Host主机 / 宿主就是用户直接交互的 AI 应用比如 Claude Desktop、VS Code AI 插件或是你自己开发的 Agent 程序。它是整个流程的起点内置了 MCP Client负责管理和协调所有客户端与服务器的连接。MCP Client客户端运行在 Host 内部的协议组件是 Host 和 Server 之间的 “翻译官”。每个 Client 对应一个 Server负责按 MCP 协议格式收发消息、处理会话和权限把大模型的调用请求转换成 MCP 指令再把工具返回的结果回传给模型。MCP Server服务器独立部署的、提供具体能力的程序比如数据库查询、文件操作、网络搜索等工具。它只需要按 MCP 标准对外暴露接口就能被任何支持 MCP 的 Host 调用真正实现 “一次开发多模型复用”。用户在 Host 里提问 → 内置的 Client 按 MCP 协议向 Server 发请求 → Server 执行工具并返回结果 → Client 再把结果交给 Host 里的大模型处理。有了 Function Calling 解决单模型工具调用再加上 MCP 解决工具跨模型复用大模型已经能稳定调用各类工具了。但在真实的业务场景中用户的需求很少是 “调用某个单一工具”而是一连串需要多工具配合的完整流程。为了让大模型能直接应对这类场景我们需要对工具进行更高一层的场景化封装 —— 这就是 Skill技能。Skill前面说了 Function Calling 如何让单模型调用工具也说了 MCP 如何让工具跨模型复用。但当面对复杂业务场景时零散的工具调用依然存在明显短板如果每次处理相同场景都要从零规划工具调用顺序、重复说明流程规则不仅沟通成本极高也容易出错。为了把成熟的业务流程沉淀下来让大模型可以一键调用完整的场景化能力我们需要对工具进行更高一层的封装 —— 这就是 Skill技能。Skill定义在 AI Agent 体系中Skill技能 是面向特定业务场景对工具、流程、规则与指令进行聚合封装后形成的一套完整、可复用的能力单元。它不是简单地把多个 Tool 打包在一起而是为了解决一个具体业务问题把 “需要哪些工具、按什么顺序调用、参数怎么传递、结果怎么处理、有哪些规则约束” 全部沉淀下来让大模型可以直接调用一整套成熟的业务流程不用每次从零开始规划。Skill组成一个完整的 Skill通常由 4 个核心部分组成组成部分核心作用通俗理解技能元信息定义技能的身份与适用场景包括名称、描述、触发条件告诉 Agent“我是做什么的什么时候该叫我干活”关联工具集完成任务所需的所有底层能力包括通过 MCP 对接的外部工具、自定义脚本、模板文件干活需要用到的 “工具包”执行编排逻辑预设工具调用的先后顺序、分支判断、参数传递规则定义完整工作流写好的 “操作说明书”规定第一步干啥、第二步干啥业务规则与指令给大模型的任务说明、输出格式要求、边界约束以及异常兜底策略任务的 “质量标准” 和 “应急预案”Skill的核心价值站在开发者和Agent 运行两个视角Skill 的核心价值降低开发者重复配置成本把固定业务流程、工具调用规则、提示指令一次性封装进 Skill开发者不用每次搭建对话、设计流程都重复定义一遍。减少大模型自主规划的流程错误预设好工具调用顺序、参数传递逻辑与分支规则不用让大模型从零即兴规划流程避免步骤错乱、参数传错、漏调用工具等问题。实现业务能力复用一套成熟 Skill 可以跨多个 Agent、多个业务场景直接复用不用重复开发同款业务逻辑。能力集中管理、维护更简单业务规则、工具关联、输出约束全部收敛在 Skill 内部后续只需修改一处所有引用该 Skill 的场景同步生效不用逐个地方改配置。Function Calling、MCP、Skill 三者关系Function Calling、MCP、Skill 三者形成由底层到上层的完整架构层级Function Calling 是大模型调用工具的底层基础能力解决模型能不能主动调用外部能力的问题MCP 是工具互联互通的标准化协议依托 Function Calling 能力实现工具一次开发、多模型跨场景复用Skill 则是在 MCP 标准化工具之上面向业务场景做流程、规则、多工具编排的高层封装把零散工具沉淀为可复用的完整业务技能。三者逐层依赖、逐层封装共同构成 AI Agent 工具调用与业务能力落地的完整体系。Skill 渐进式披露虽然 Skill 解决了流程封装的问题但新的挑战随之而来如果把所有 Skill 的完整信息一次性全塞给大模型不仅会让上下文 Token 瞬间膨胀还会导致大模型因技能过多而出现匹配混乱、误调用的问题。为了解决这个矛盾就有了 Skill 渐进式披露 的设计思路不把所有 Skill 的全部信息一次性暴露给大模型而是按需、分阶段地开放。在实际实现中它有两种非常经典的设计方式方式一按加载粒度分层Token 优化方案从技术实现的角度把一个 Skill 的完整信息拆成三层只在真正需要时才加载对应部分元数据MetadataAgent 启动时仅加载所有 Skill 的 name 和 description让 Agent 知道 “我有哪些技能”但只占极少 Token完整指令正文当用户需求触发相关 Skill 时才把该 Skill 的完整流程、指令加载进上下文附属资源脚本、模板、参考文档等仅在执行过程中真正需要时才读取。这种设计能把绝大多数 Token 消耗推迟到真正需要的时候避免上下文被大量无关信息 “撑爆”。方式二按业务场景 / 权限分层安全管控方案从业务安全与效率的角度根据 Skill 的使用场景和权限等级控制它们对大模型的可见范围基础层通用必备技能闲聊、帮助启动时永久披露始终可用场景层业务场景技能办公、出行识别到场景后动态披露用完可回收敏感层高权限操作删除、支付用户授权 / 校验后才披露防止误操作。RagRAG Retrieval-Augmented Generation检索增强生成简单来说大模型的训练知识有时间截止也无法知晓我们私有的文档、业务资料、内部知识库RAG 的核心作用就是先从私有知识库检索相关内容再把检索到的资料喂给大模型让模型依据真实文档作答有效解决知识滞后、无法使用私有数据、模型幻觉瞎编等问题。知识库在 RAG 里要给大模型补充外部知识首先得有一个存放这些知识的 “容器”—— 这就是知识库。知识库定义它是经过整理、清洗的资料集合比如产品文档、FAQ、技术手册、行业规范、内部流程等。这些内容会被统一管理成为大模型可以参考的权威事实依据。知识库的作用解决大模型 “知识过时、不懂业务、容易幻觉” 的问题。让回答有事实依据不是模型瞎编。知识库不是一个简单的文档存储工具它是连接静态文档和动态AI应用的桥梁是整个AI应用体系的基础设施。但有了知识库还不够如果只用关键词匹配很容易漏掉语义相近但字面不同的内容效率低、不准。要实现 “语义级快速检索”就需要把知识转成向量再用专门的数据库来管理也就是向量数据库。向量数据库向量定义在 AI 领域文本、图片、音频等都属于非结构化数据计算机无法直接理解。通过Embedding 模型可以把这类数据转换成一串固定长度的高维数字数组这串数字就是向量。向量的每一个维度都承载着对应数据的语义或特征信息文本向量承载语句的语义含义行人 / 图像向量承载外观、轮廓、身形等视觉特征为什么不用普通数据库MySQL 等传统关系型数据库擅长精准匹配适合结构化数据的等值查询、条件筛选。但高维向量有两个关键特点维度极高通常几百到上千维业务需要的不是完全相等而是相似度匹配。如果用普通数据库存储向量只能逐条暴力计算相似度数据量大时检索速度极慢完全无法满足 RAG、行人重识别等线上业务的秒级响应需求。向量数据库定义向量数据库是专门面向高维向量设计用于存储、索引、管理海量向量并提供高速相似度检索的专用数据库。核心核心能力就三点安全海量存储高维向量构建专用向量索引优化检索效率输入查询向量快速召回库中相似度最高的 Top-K 结果。向量数据库与普通数据库对比向量数据库之所以能实现 “又快又准” 的检索核心秘密就是 ANN 索引Approximate Nearest Neighbor近似最近邻索引。它是一种专门为高维向量设计的检索算法通过提前对海量向量进行聚类、分层、建图构建出一张能快速导航的 “地图”。速度快的核心传统数据库面对海量高维向量只能逐条暴力计算相似度检索效率极低而 ANN 索引让检索时无需遍历全量数据只需在相近的小范围里做匹配计算量大幅减少从而实现亿级数据下的毫秒级召回。我们常说的 HNSW、IVF 等算法都是 ANN 索引的主流实现。结果准的核心它跳出了传统关键词字面匹配的局限借助高维 Embedding 向量承载文本语义或图像细粒度特征再通过余弦相似度、欧氏距离等专业度量方式计算向量间的相似程度能够精准识别语义相近、特征相似的内容让检索结果更贴合用户真实意图。常见主流向量数据库轻量入门首选Chroma特点Python 原生的本地轻量级向量数据库几乎零配置几行代码就能跑通完整流程是新手学习、快速验证 RAG 原型的最低摩擦选择。适合场景本地开发、功能验证、学习跑 Demo。局限不支持高可用、分布式部署不适合直接上生产环境。高性能检索引擎FAISS特点Meta 开源的向量检索引擎专注于高性能向量相似度计算检索速度极快常作为核心组件搭配自定义数据存储使用。适合场景需要嵌入到现有项目中做本地或小规模向量检索的场景。局限本身不提供完整的数据库服务需要自己额外处理数据存储、持久化等逻辑。工业级私有化方案Milvus特点开源的工业级向量数据库功能最全面支持多种索引类型、分布式部署与数据持久化社区活跃、文档完善。适合场景数据必须内网部署、需要精细控制、规模较大的企业级生产环境。局限部署与运维复杂度较高学习曲线比轻量工具更陡。高性能低资源方案Qdrant特点基于 Rust 实现的高性能向量数据库内存占用低、查询速度快接口设计简洁支持 HTTP/gRPC。适合场景对性能和资源消耗敏感的生产环境比如在有限硬件上跑大规模高并发检索。多模态友好方案Weaviate特点开源向量数据库内置 Embedding 模型集成支持直接处理文本、图片、音频等多模态数据无需自己单独调用模型生成向量。适合场景需要多模态检索或希望简化 Embedding 处理步骤的场景。全托管云服务Pinecone特点全托管的云向量数据库无需管理服务器、扩容、备份等基础设施开箱即用只需调用 API 即可。适合场景小团队 / 创业公司快速上线 RAG 服务不想投入专职运维人员。局限数据存储在第三方存在合规顾虑按用量收费大规模使用成本较高。RAG 两大核心阶段RAG 的整个工作流程可划分为离线预处理数据准备和在线推理问答生成两个核心阶段。一、第一阶段离线预处理索引构建阶段也叫入库阶段、准备阶段特点提前做、一次性 / 定时做用户提问时不参与核心动作收集私有文档PDF、Word、笔记、业务手册、网页文档等文本切片分块Chunk 拆分对每个文本块做 Embedding 向量化将向量与原文存入向量数据库核心目的把非结构化文档变成可被语义检索的向量索引为 RAG 提前备好可用的知识库。二、第二阶段在线推理检索生成阶段也叫问答阶段 / 实时交互阶段特点用户一问立刻实时执行核心动作核心目的用户提问时临时检索私有资料让模型照着真实文档回答解决 “瞎编、不懂业务、知识过时” 的问题。用户输入问题召回问题做 Embedding 向量化去向量库语义检索捞出相似度最高的文档片段重排对召回结果做二次筛选选出最相关的片段生成把「检索到的原文 用户问题」一起拼接近 Prompt大模型基于真实资料生成答案RAG 完整四步工作流程在两大阶段基础上可细化为标准四步执行流程文档预处理将 PDF、笔记、业务文档等进行文本切分、向量化存入向量数据库检索Retrieval用户发起提问时从向量库中匹配捞出最相关的文档片段增强Augmented把检索到的真实资料拼接进提示词作为模型回答的依据生成Generation大模型参考给定的专业资料输出准确、有据可依的答案。RAG 与 Function Calling、MCP、Skill 的层级关系Function Calling大模型底层基础能力让模型具备主动识别意图、主动调用外部能力的能力MCP工具标准化协议统一各类外部能力的接入规范RAG一种专门用于私有知识库检索的特殊工具能力Skill在 MCP 标准化工具之上把 RAG、其他业务工具、执行流程、业务规则统一编排封装形成完整可复用的业务场景能力。完整运行链路下面我们从「底层技术」和「业务应用」两个视角分别还原一次完整的问答过程RAG 底层向量运行链路技术原理视角前面我们了解了知识库、向量数据库的分工这里用一段链路讲清 RAG 内部的核心逻辑知识库输出原始文本内容由 Embedding 模型将文本转为语义向量让机器理解文本语义向量数据库存储向量并构建 ANN 索引实现快速检索用户问题同样转为向量在向量库中检索相似内容召回原始文档片段喂给大模型生成答案Agent 完整运行链路业务高层视角用户提出专业知识类问题大模型通过 Function Calling 判断需要检索内部资料调用经过 MCP 标准化封装的 RAG 工具从私有知识库检索匹配相关文档片段交由 Skill 统一编排问答逻辑、输出格式与约束规则最终给出贴合业务、有据可查、低幻觉的回答有 RAG 和没有 RAG 的核心差异对比维度没有 RAG 的 Agent / 大模型有 RAG 的 Agent / 大模型知识来源仅依赖模型训练阶段的静态知识存在时间截止模型静态知识 私有 / 最新知识库双来源私有数据支持无法访问企业内部文档、业务手册等私有数据可直接调用私有知识库回答完全贴合业务场景回答准确性对专业 / 业务问题容易出现幻觉、编造数据回答以真实文档为依据可溯源幻觉大幅降低知识更新成本极高只能通过重新训练 / 微调模型更新知识极低只需更新知识库文档模型回答同步生效定制化难度高依赖模型微调成本高、周期长低维护知识库即可快速实现业务定制合规与私有化难以满足输出内容不可控数据完全私有可控更容易满足合规要求典型应用场景通用闲聊、创意生成、公开常识问答企业内部问答、客服知识库、文档助手、专业顾问前面我们已经了解了 RAG、向量数据库、函数调用、Skill 技能、MCP 协议等各类能力组件。但这些零散的能力本身并不能自动变成一个完整可运行的 AI Agent。大模型只负责思考和生成指令各类工具只负责单一功能执行中间缺少一套统一调度、流程控制、状态管理、任务编排的工程层来把它们串联起来。而承担这一串联、调度、管控角色的核心概念就是 Harness。HarnessHarness定义在 AI Agent 领域有一个核心公式Agent 大模型 Model HarnessModel大模型只负责思考、推理、生成指令是 Agent 的大脑只会输出文本和决策意图不会主动调用工具、不会管理流程、不会维护状态。Harness可以理解为智能驾驭层 / 工程调度骨架是大模型以外所有用来串联、调度、管控、执行的整套工程系统。通俗比喻大模型是司机只会思考往哪走、做什么决策Harness 是车身 方向盘 控制系统 交通规则负责帮司机控车、认路、遵守规则、处理突发情况让决策真正落地执行。为什么必须要有 Harness如果只有大模型没有 Harness模型想调用工具没有逻辑帮它解析参数、发起调用多步任务没法自动循环只能一问一答没有记忆和状态记不住上下文、任务进度没有安全限制容易越权、乱调用、无限循环RAG、Skill、MCP、函数调用这些能力散落各处无法联动。Harness 的核心作用把大模型的 “想法”变成能落地的 “行动”。Harness 的核心环节要把 “只会聊天的裸模型” 变成 “能干活的 Agent”Harness 的工作可以拆成 6 个核心环节它们从输入到输出完整覆盖了 Agent 运行的全流程上下文精细化解决的问题模型这一轮该看到什么信息负责处理输入信息比如 RAG 召回的知识、工具返回的结果、对话历史通过过滤、摘要、排序等方式给模型提供精简且关键的上下文避免信息过载。工具系统解决的问题模型可以用哪些能力执行操作统一管理 Function Calling、Skill 技能、RAG 知识库、第三方 API 等所有能力组件为模型提供可调用的 “工具库”让它的指令能真正转化为实际操作。执行编排解决的问题模型下一步该如何推进任务驱动「思考 → 决策 → 调用工具 → 观察结果 → 再思考」的闭环循环控制多步骤任务的推进节奏让 Agent 能自主完成复杂任务而不是只能一问一答。记忆与状态解决的问题模型跨轮次需要保留哪些状态维护会话历史、任务进度、用户偏好、临时数据等状态信息让 Agent 能记住对话上下文、任务进度实现连贯对话和长任务执行。评估与观测解决的问题如何判断模型的执行效果与状态给 Agent 的执行加上 “可观测性”记录调用日志、任务链路、错误信息同时通过结果校验、目标评估判断任务是否完成让问题可追溯、可复盘。约束与恢复解决的问题如何在出错时保障系统稳定并恢复运行为 Agent 加上安全护栏与异常处理机制比如权限控制、调用次数限制、敏感操作拦截同时处理工具调用失败、超时、死循环等异常让 Agent 即使出错也能安全兜底、继续运行。
