企业官网建设流程全解析

本文将带你从零到一，系统性梳理 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 的出现，正好弥补了这一短板。

Agent

Agent定义

Agent 是由大模型驱动的智能系统，它的核心作用，就是解决传统大模型只能单次问答、无法自主执行复杂任务的短板。通过自主规划、调用工具、动态调整执行路径，让大模型从单纯的聊天应答，升级为能独立完成多步骤任务的智能体。
Agent 的本质，就是让大模型在循环中不断根据新信息做决策、调工具，直到任务完成。

Agent核心组成

Agent 是由大模型（决策大脑）、工具（执行双手）、记忆（信息存储）与「思考 - 行动 - 观察 - 再思考」的执行循环构成的智能体。

• 大模型（LLM，大脑）
  整个 Agent 的决策核心，负责理解任务、分析状态、推理并决定下一步该做什么。所有的 “思考” 和判断，都由它完成。
• 工具（Tools，双手）
  让 Agent 能与外部世界交互的执行单元，比如查数据库、搜引擎、读写文件、调用 API 等。大模型发指令，工具负责执行，再把结果返回给模型。
• 记忆（Memory，记事本）
  负责记录信息，是串联多步骤任务的关键：
  短期记忆：对话历史、工具返回结果，存在上下文窗口里
  长期记忆：跨会话的持久信息，存在外部数据库中
• 执行循环（Loop，节拍器）
  Agent 的核心引擎，也是它和普通大模型调用的根本区别。通过「思考→行动→观察→再思考」的闭环，不断迭代，直到任务完成。

Agent 的核心价值，在于融合大模型的推理能力与工具的执行能力，让系统能处理无法穷举所有情况的复杂任务。

Agent 与工作流的区别

工作流是固定规则、按预设流程跑；Agent 是大模型自主思考、动态决策、能随机应变。

对比维度	Workflow（工作流）	Agent （智能体）
决策核心	固定硬编码规则	大模型自主推理
执行路径	固定不变	动态调整
灵活性	差，遇异常易卡住	强，可临场应变
适用场景	步骤明确、重复性高的标准化任务	目标开放、情况多变的复杂任务
可预测性	高，流程结果可控	低，结果受模型影响
成本	低，无大模型调用	高，依赖多轮 LLM 调用
维护方式	业务一变需改流程、改代码	调整提示词或工具，无需重构

Agent 的核心机制与工作范式

Agent 的所有复杂功能，都建立在一个最基础的循环逻辑之上，本质是一个「决策→执行→反馈→再决策」的闭环。
核心四步流程

1. 调大模型，让它决策
   接收用户任务，由大模型根据当前上下文，决定下一步要做什么（调用什么工具、执行什么动作）。
2. 判断是否完成
   大模型同时判断当前任务是否达成目标。如果完成，就退出循环；如果没完成，继续执行。
3. 没完成就执行工具，把结果追加进 messages
   根据决策结果调用工具（如 API、数据库、搜索引擎），并将工具返回的结果，追加到消息列表（上下文）中。
4. 带着新结果再调大模型，进入下一轮
   大模型结合上一轮的工具结果，重新决策，进入下一轮循环。

简单来说，Agent 的本质，就是让大模型在循环中不断根据新信息做决策、调工具，直到任务完成。基于这个基础循环，衍生出了三种常见的工作范式：

1. ReAct（Reasoning推理 + Acting行动交替范式）
   核心逻辑：Thought（思考）→ Action（行动）→ Observation（观察） 循环执行，走一步看一步，边推理边执行。
   特点：不提前制定完整计划，每一步的行动都依赖上一步的结果反馈，能灵活处理不确定的复杂任务，适合步骤少、目标模糊、需要随机应变的场景（如对话式问题排查、实时信息查询、轻量故障处理）。

2. Plan-and-Execute（规划 - 执行范式）
   核心逻辑：一个「规划 - 执行 - 评估 - 调整」的持续闭环：它会先通过大模型制定一份清晰、可拆解的全局执行计划，将复杂目标分解为一系列可落地的子任务；随后按计划依次执行子任务，并根据工具反馈与环境变化动态评估执行效果、调整后续计划，不断迭代优化，直至目标完成。
   特点：先定全局路线，再分步执行，适合流程相对固定、目标明确的长任务，可控性强。

3. Reflection（反思 / 复盘范式）
   核心逻辑：在执行完成后，加入「评估 - 反思 - 修正」环节，通过自我检查、复盘错误，再重新执行，不断优化结果质量。
   特点：通过 “质量飞轮” 持续迭代，能大幅降低错误率，适合对结果质量要求高的场景（如代码生成、写作）。

对比表格

对比维度	ReAct	Plan-and-Execute	Reflection
决策时机	每一步实时决策	开始前一次性规划	执行后延迟决策（对结果做二次判断）
全局视野	弱（只看当前这步）	强（提前看到任务全貌）	中（基于完整执行结果做复盘，视野随迭代扩大）
灵活性	强（可随时根据结果调整方向）	弱（计划一旦生成，调整成本较高）	中（调整成本集中在反思环节，需重新执行）
适合任务步骤	少（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 做执行，决策之后调用工具、拿到结果再反馈给大模型，形成完整循环，实现自主完成任务。
• 拆解复杂任务，分工协作
  复杂任务可以拆成多个小环节，每个环节对应一个专用 Tool，Agent 按需组合调用不同工具，就能一步步完成多步骤复杂工作。

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 精准解析和执行，从而实现与外部工具的间接交互。

你可以把它理解成大模型的「指令翻译器」：

1. 你提前给大模型喂了所有 Tool 的 name、description、parameters（也就是工具清单）；
2. 用户问了一个需要联网 / 查数据才能回答的问题；
3. 大模型通过 Function Calling 能力，判断出 “我需要调用哪个工具、该传什么参数”，并生成标准的工具调用指令；
4. 你的 Agent 系统拿到指令后，去执行工具，再把结果返回给大模型；
5. 大模型基于工具返回的结果，整理出最终答案回复给用户。

它的核心作用，就是让大模型从 “只会聊天”，变成 “能主动使用工具解决问题”，这也是所有 Agent 能跑起来的底层基础。

它和 Tool、Agent 的关系

• Tool：是你写好的、能干活的具体功能（比如搜索、查天气）；
• Function Calling：是大模型调用这些 Tool 的 “能力” 和 “标准协议”；
• Agent：是基于大模型 + Function Calling + Tool 搭建起来的完整系统。

没有 Function Calling，大模型就不知道该怎么调用你写的 Tool

举例
用户问：“今天北京天气怎么样？”

1. 你提前给大模型定义了一个 get_weather 工具，说明它的用途是 “查询指定城市的天气”，参数是 city；
2. 大模型通过 Function Calling 能力，判断需要调用 get_weather工具，并生成调用指令：{“name”: “get_weather”, “parameters”: {“city”: “北京”}}；
3. 系统执行这个工具，拿到 “晴，25℃” 的结果，返回给大模型；
4. 大模型基于结果，回复用户：“今天北京天气晴，气温 25℃。”

核心组成

一次完整的 Function Calling 工具调用流程，由三部分构成，三者缺一不可：

• 工具定义（Function Definition）
  也就是给大模型的「工具说明书」，是大模型判断是否调用、如何调用工具的核心依据。包含工具名称、功能描述、参数格式，和前面讲解的 Tool 关键要素完全对应。
• 工具调用请求（Function Call Request）
  大模型结合用户问题和已有的工具定义，自动生成标准化调用指令。以结构化 JSON 格式输出，明确指定要调用的工具名称和所需传入的参数值，相当于大模型下发的执行指令。
• 工具执行与结果返回（Function Execution & Response）
  Agent 系统接收调用指令后，运行提前编写好的工具业务逻辑（函数本体）；执行完成后，将返回结果做格式化处理，再回传给大模型。大模型依据工具返回内容，整理最终回答，或进入下一轮决策循环。

整体流程可以简单概括为：开发者下发工具定义 → 大模型生成工具调用请求 → 系统执行工具并返回结果 → 大模型基于结果继续处理任务。

Agent 标准执行闭环流程
用户提问 → Agent 打包「需求 + 工具清单」发给大模型 → 大模型决策并生成 Function Calling 指令 → Agent 解析指令并执行工具 → 工具结果回传大模型 → 大模型判断下一步 → 循环执行直到任务完成 → Agent 反馈最终结果给用户

1. 接收用户提问
   用户输入需求、问题或任务指令，进入 Agent 系统。
2. 打包上下文，发送给大模型
   Agent 会把用户的原始需求以及提前定义好的工具清单，一起打包发送给大模型。
3. 大模型思考决策，触发 Function Calling
   大模型理解用户意图，结合工具清单判断：能不能直接回答，还是必须调用工具。如果需要联网、查数据或执行操作，就通过 Function Calling 生成标准化的工具调用请求（JSON 格式）。
4. Agent 解析指令并执行工具
   Agent 系统解析大模型发来的调用信息，识别要调用的工具和参数，运行对应的工具底层函数本体，完成实际操作：搜索、查库、读写文件、调用接口等。
5. 工具结果回传大模型
   把工具执行拿到的结果，整理格式化后，重新发给大模型。
6. 大模型判断下一步
   大模型根据工具返回的真实数据，重新评估任务状态：是可以直接整理答案回复用户，还是需要继续调用其他工具？
7. 循环执行，直到任务完成
   如果任务还没完成，就会重复「决策→调用工具→结果回传」的闭环；直到所有必要操作完成，大模型生成最终答案。
8. Agent 反馈最终结果
   Agent 将大模型整理好的最终答案，以自然语言的形式反馈给用户，整个流程结束。

Function Calling 虽然能让单款大模型顺利调用工具，但它属于厂商私有规范，不同大模型的调用格式不统一，工具无法跨模型复用。为了解决这个痛点，行业推出了一套跨模型通用开放标准协议——MCP。

MCP

MCP（Model 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 运行在 Host（AI 应用/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 的完整信息拆成三层，只在真正需要时才加载对应部分：

• 元数据（Metadata）：Agent 启动时，仅加载所有 Skill 的 name 和 description，让 Agent 知道 “我有哪些技能”，但只占极少 Token；
• 完整指令（正文）：当用户需求触发相关 Skill 时，才把该 Skill 的完整流程、指令加载进上下文；
• 附属资源：脚本、模板、参考文档等，仅在执行过程中真正需要时才读取。

这种设计能把绝大多数 Token 消耗推迟到真正需要的时候，避免上下文被大量无关信息 “撑爆”。

方式二：按业务场景 / 权限分层（安全管控方案）
从业务安全与效率的角度，根据 Skill 的使用场景和权限等级，控制它们对大模型的可见范围：

• 基础层：通用必备技能（闲聊、帮助），启动时永久披露，始终可用；
• 场景层：业务场景技能（办公、出行），识别到场景后动态披露，用完可回收；
• 敏感层：高权限操作（删除、支付），用户授权 / 校验后才披露，防止误操作。

Rag

RAG （Retrieval-Augmented Generation，检索增强生成），简单来说：大模型的训练知识有时间截止，也无法知晓我们私有的文档、业务资料、内部知识库；RAG 的核心作用，就是先从私有知识库检索相关内容，再把检索到的资料喂给大模型，让模型依据真实文档作答，有效解决知识滞后、无法使用私有数据、模型幻觉瞎编等问题。

知识库

在 RAG 里，要给大模型补充外部知识，首先得有一个存放这些知识的 “容器”—— 这就是知识库。

知识库定义

它是经过整理、清洗的资料集合，比如产品文档、FAQ、技术手册、行业规范、内部流程等。这些内容会被统一管理，成为大模型可以参考的权威事实依据。

知识库的作用

• 解决大模型 “知识过时、不懂业务、容易幻觉” 的问题。
• 让回答有事实依据，不是模型瞎编。

知识库不是一个简单的文档存储工具，它是连接静态文档和动态AI应用的桥梁，是整个AI应用体系的基础设施。

但有了知识库还不够：
如果只用关键词匹配，很容易漏掉语义相近但字面不同的内容，效率低、不准。
要实现 “语义级快速检索”，就需要把知识转成向量，再用专门的数据库来管理，也就是向量数据库。

向量数据库

向量定义

在 AI 领域，文本、图片、音频等都属于非结构化数据，计算机无法直接理解。通过Embedding 模型，可以把这类数据转换成一串固定长度的高维数字数组，这串数字就是向量。
向量的每一个维度，都承载着对应数据的语义或特征信息：

• 文本向量：承载语句的语义含义
• 行人 / 图像向量：承载外观、轮廓、身形等视觉特征

为什么不用普通数据库

MySQL 等传统关系型数据库，擅长精准匹配，适合结构化数据的等值查询、条件筛选。但高维向量有两个关键特点：维度极高，通常几百到上千维；业务需要的不是完全相等，而是相似度匹配。
如果用普通数据库存储向量，只能逐条暴力计算相似度，数据量大时检索速度极慢，完全无法满足 RAG、行人重识别等线上业务的秒级响应需求。

向量数据库定义

向量数据库是专门面向高维向量设计，用于存储、索引、管理海量向量，并提供高速相似度检索的专用数据库。核心核心能力就三点：

• 安全海量存储高维向量；
• 构建专用向量索引，优化检索效率；
• 输入查询向量，快速召回库中相似度最高的 Top-K 结果。

向量数据库与普通数据库对比

向量数据库之所以能实现 “又快又准” 的检索，核心秘密就是 ANN 索引（Approximate Nearest Neighbor，近似最近邻索引）。
它是一种专门为高维向量设计的检索算法，通过提前对海量向量进行聚类、分层、建图，构建出一张能快速导航的 “地图”。

• 速度快的核心：传统数据库面对海量高维向量，只能逐条暴力计算相似度，检索效率极低；而 ANN 索引让检索时无需遍历全量数据，只需在相近的小范围里做匹配，计算量大幅减少，从而实现亿级数据下的毫秒级召回。我们常说的 HNSW、IVF 等算法，都是 ANN 索引的主流实现。
• 结果准的核心：它跳出了传统关键词字面匹配的局限，借助高维 Embedding 向量承载文本语义或图像细粒度特征，再通过余弦相似度、欧氏距离等专业度量方式计算向量间的相似程度，能够精准识别语义相近、特征相似的内容，让检索结果更贴合用户真实意图。

常见主流向量数据库

1. 轻量入门首选：Chroma
   特点：Python 原生的本地轻量级向量数据库，几乎零配置，几行代码就能跑通完整流程，是新手学习、快速验证 RAG 原型的最低摩擦选择。
   适合场景：本地开发、功能验证、学习跑 Demo。
   局限：不支持高可用、分布式部署，不适合直接上生产环境。
2. 高性能检索引擎：FAISS
   特点：Meta 开源的向量检索引擎，专注于高性能向量相似度计算，检索速度极快，常作为核心组件搭配自定义数据存储使用。
   适合场景：需要嵌入到现有项目中，做本地或小规模向量检索的场景。
   局限：本身不提供完整的数据库服务，需要自己额外处理数据存储、持久化等逻辑。
3. 工业级私有化方案：Milvus
   特点：开源的工业级向量数据库，功能最全面，支持多种索引类型、分布式部署与数据持久化，社区活跃、文档完善。
   适合场景：数据必须内网部署、需要精细控制、规模较大的企业级生产环境。
   局限：部署与运维复杂度较高，学习曲线比轻量工具更陡。
4. 高性能低资源方案：Qdrant
   特点：基于 Rust 实现的高性能向量数据库，内存占用低、查询速度快，接口设计简洁，支持 HTTP/gRPC。
   适合场景：对性能和资源消耗敏感的生产环境，比如在有限硬件上跑大规模高并发检索。
5. 多模态友好方案：Weaviate
   特点：开源向量数据库，内置 Embedding 模型集成，支持直接处理文本、图片、音频等多模态数据，无需自己单独调用模型生成向量。
   适合场景：需要多模态检索，或希望简化 Embedding 处理步骤的场景。
6. 全托管云服务：Pinecone
   特点：全托管的云向量数据库，无需管理服务器、扩容、备份等基础设施，开箱即用，只需调用 API 即可。
   适合场景：小团队 / 创业公司快速上线 RAG 服务，不想投入专职运维人员。
   局限：数据存储在第三方，存在合规顾虑；按用量收费，大规模使用成本较高。

RAG 两大核心阶段

RAG 的整个工作流程可划分为离线预处理（数据准备）和在线推理（问答生成）两个核心阶段。

一、第一阶段：离线预处理（索引构建阶段）
也叫：入库阶段、准备阶段
特点：提前做、一次性 / 定时做，用户提问时不参与
核心动作：

1. 收集私有文档（PDF、Word、笔记、业务手册、网页文档等）
2. 文本切片分块（Chunk 拆分）
3. 对每个文本块做 Embedding 向量化
4. 将向量与原文存入向量数据库

核心目的：
把非结构化文档，变成可被语义检索的向量索引，为 RAG 提前备好可用的知识库。

二、第二阶段：在线推理（检索生成阶段）
也叫：问答阶段 / 实时交互阶段
特点：用户一问，立刻实时执行
核心动作：

核心目的：用户提问时临时检索私有资料，让模型照着真实文档回答，解决 “瞎编、不懂业务、知识过时” 的问题。

1. 用户输入问题
2. 召回：问题做 Embedding 向量化，去向量库语义检索，捞出相似度最高的文档片段
3. 重排：对召回结果做二次筛选，选出最相关的片段
4. 生成：把「检索到的原文 + 用户问题」一起拼接近 Prompt，大模型基于真实资料生成答案

RAG 完整四步工作流程

在两大阶段基础上，可细化为标准四步执行流程：

1. 文档预处理：将 PDF、笔记、业务文档等进行文本切分、向量化，存入向量数据库；
2. 检索（Retrieval）：用户发起提问时，从向量库中匹配捞出最相关的文档片段；
3. 增强（Augmented）：把检索到的真实资料拼接进提示词，作为模型回答的依据；
4. 生成（Generation）：大模型参考给定的专业资料，输出准确、有据可依的答案。

RAG 与 Function Calling、MCP、Skill 的层级关系

• Function Calling：大模型底层基础能力，让模型具备主动识别意图、主动调用外部能力的能力；
• MCP：工具标准化协议，统一各类外部能力的接入规范；
• RAG：一种专门用于私有知识库检索的特殊工具能力；
• Skill：在 MCP 标准化工具之上，把 RAG、其他业务工具、执行流程、业务规则统一编排封装，形成完整可复用的业务场景能力。

完整运行链路

下面我们从「底层技术」和「业务应用」两个视角，分别还原一次完整的问答过程：

RAG 底层向量运行链路（技术原理视角）

前面我们了解了知识库、向量数据库的分工，这里用一段链路讲清 RAG 内部的核心逻辑：

1. 知识库输出原始文本内容
2. 由 Embedding 模型将文本转为语义向量（让机器理解文本语义）
3. 向量数据库存储向量并构建 ANN 索引（实现快速检索）
4. 用户问题同样转为向量，在向量库中检索相似内容
5. 召回原始文档片段，喂给大模型生成答案

Agent 完整运行链路（业务高层视角）

1. 用户提出专业知识类问题
2. 大模型通过 Function Calling 判断需要检索内部资料
3. 调用经过 MCP 标准化封装的 RAG 工具
4. 从私有知识库检索匹配相关文档片段
5. 交由 Skill 统一编排问答逻辑、输出格式与约束规则
6. 最终给出贴合业务、有据可查、低幻觉的回答

有 RAG 和没有 RAG 的核心差异

对比维度	没有 RAG 的 Agent / 大模型	有 RAG 的 Agent / 大模型
知识来源	仅依赖模型训练阶段的静态知识，存在时间截止	模型静态知识 + 私有 / 最新知识库双来源
私有数据支持	无法访问企业内部文档、业务手册等私有数据	可直接调用私有知识库，回答完全贴合业务场景
回答准确性	对专业 / 业务问题容易出现幻觉、编造数据	回答以真实文档为依据，可溯源，幻觉大幅降低
知识更新成本	极高，只能通过重新训练 / 微调模型更新知识	极低，只需更新知识库文档，模型回答同步生效
定制化难度	高，依赖模型微调，成本高、周期长	低，维护知识库即可快速实现业务定制
合规与私有化	难以满足，输出内容不可控	数据完全私有可控，更容易满足合规要求
典型应用场景	通用闲聊、创意生成、公开常识问答	企业内部问答、客服知识库、文档助手、专业顾问

前面我们已经了解了 RAG、向量数据库、函数调用、Skill 技能、MCP 协议等各类能力组件。但这些零散的能力本身，并不能自动变成一个完整可运行的 AI Agent。
大模型只负责思考和生成指令，各类工具只负责单一功能执行，中间缺少一套统一调度、流程控制、状态管理、任务编排的工程层来把它们串联起来。而承担这一串联、调度、管控角色的核心概念，就是 Harness。

Harness

Harness定义

在 AI Agent 领域有一个核心公式：Agent = 大模型 Model + Harness
Model（大模型）：只负责思考、推理、生成指令，是 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 即使出错也能安全兜底、继续运行。