一、AI 自动化协作体系中的关键概念解析

1. 初始 AI 模型交互与提示词演进

1.1 用户提示词 (User Prompt)

• 定义：用户发送给 AI 模型的消息，通常是提出的问题或表达的意图。
• 局限性：
  • AI 模型缺乏预设的 “人设” 或 “背景”。
  • 只能提供通用、中规中矩的回答，缺乏个性化和趣味性。
  • 即便面对相同的问题，也无法根据不同的上下文或角色给出差异化的反馈。

1.2 系统提示词 (System Prompt)

• 产生背景：为解决 AI 模型缺乏人设的问题，早期尝试是将人设信息与用户请求打包进同一条用户提示词中，但这使得请求内容显得不自然。
• 定义：将 AI 模型的人设、性格、背景信息、语气等独立出来的提示信息。只要不是用户直接说出的内容，都可以放置于系统提示词中。
• 机制：每次用户发送用户提示词时，系统会自动将系统提示词一同发送给 AI 模型，使对话更自然。
• 应用场景：
  • 网页端聊天机器人中，系统提示词常由系统预设，用户可能无法直接修改。
  • 部分平台（如 ChatGPT 的 Customized ChatGPT 功能）允许用户自定义偏好，这些偏好会自动整合为系统提示词的一部分。

---

2. AI 智能体 (AI Agent) 及其工具 (Agent Tool)

2.1 AI Agent 的引入

• 需求背景：AI 模型仅能提供答案或操作建议，无法自主执行任务。
• 概念：
  • AI Agent：负责在 AI 模型、工具和最终用户之间进行协调和通信的程序。
  • Agent Tool：提供给 AI 模型调用的函数或服务。
• 早期突破 (AutoGPT 示例)：
  • AutoGPT 架构：一个本地运行的小程序。
  • 工具注册：需预先编写并注册文件管理函数（如list_files、read_files），并提供其功能描述和返回格式。
  • 系统提示词生成：AutoGPT 根据注册的工具信息，生成一个系统提示词，告知 AI 模型可用的工具、其功能以及调用时应返回的格式。
  • 任务流程：
    1. 用户请求（例如 “帮我找一找原神的安装目录”）与包含工具信息的系统提示词一同发送给 AI 模型。
    2. AI 模型若足够智能，会根据要求格式返回一个调用特定函数的请求。
    3. AutoGPT 解析请求，调用对应函数。
    4. 函数执行结果返回给 AI 模型。
    5. AI 模型根据结果决定下一步操作。
    6. 此过程反复进行，直至任务完成。

2.2 早期 Agent 架构的挑战

• 格式不确定性：AI 模型作为概率模型，即便在系统提示词中明确规定了返回格式，仍有可能生成格式不符的内容。
• 解决方案 (客户端重试)：许多 AI Agent 在检测到 AI 返回格式错误时，会自动进行重试。
• 现状：部分知名 Agent（如 kline）仍采用此方式，但重试机制增加了不确定性和开发复杂度。

---

3. 函数调用 (Function Calling)

3.1 Function Calling 的提出

• 背景：为解决早期 Agent 架构中 AI 返回格式不确定的问题，大型模型厂商（如 ChatGPT、Claude、Gemini）推出了 Function Calling 功能。
• 核心思想：统一工具描述和 AI 调用工具时的返回格式规范。

3.2 Function Calling 的机制

• 工具描述标准化：
  • 每个工具都使用 JSON 对象进行定义。
  • 工具名（name）、功能说明（description）、所需参数（parameters）等字段被标准化。
  • 这些 JSON 对象不再置于系统提示词中，而是单独存放于一个特定字段。
• AI 返回格式规定：Function Calling 明确规定了 AI 模型使用工具时应返回的格式，从而消除了系统提示词中对格式定义的需要。
• 优化效果：
  • 所有工具描述集中且格式统一。
  • AI 模型调用工具的回复格式也得到统一。
  • 便于大模型厂商更有针对性地训练 AI 模型，使其更好地理解和执行工具调用场景。
  • 即使 AI 生成了错误回复，由于格式固定，AI 服务器端可自行检测并进行重试，用户端无感知，降低了用户端的开发难度和重试带来的 Token 开销。

3.3 Function Calling 的局限性

• 缺乏统一标准：各大模型厂商的 API 定义不同，未形成行业通用标准。
• 兼容性问题：许多开源模型尚未支持 Function Calling。
• 现状：Function Calling 与系统提示词两种方式在市场上并存，因各自优劣而适用于不同场景。

---

4. MCP 协议 (Agent 与 Tool 服务的通信)

4.1 MCP 的诞生背景

• 问题：某些 Agent Tool 的功能具有通用性（如网页浏览工具），若每个 Agent 都独立拷贝一份代码，将导致重复且不优雅。
• 解决方案：将 Agent Tool 服务化，进行统一托管，供所有 Agent 调用。

4.2 MCP 定义与组件

• 定义：MCP (Model Context Protocol) 是一个通信协议，专门用于规范 Agent 与 Tool 服务之间的交互方式。
• 核心组件：
  • MCP Server：运行 Agent Tool 服务的服务器。
  • MCP Client：调用 MCP Server 上 Agent Tool 服务的 Agent。
• MCP 规范内容：
  • 定义了 MCP Server 与 MCP Client 之间的通信方式。
  • 规定了 MCP Server 需提供的接口，例如查询可用的 Tool、Tool 的功能描述、所需参数格式等。

4.3 MCP Server 提供的服务类型

• Tool：提供函数调用形式的服务。
• Resource：提供数据，类似于文件读写服务。
• Prompt：为 Agent 提供提示词模板。

4.4 MCP 的部署方式

• 可与 Agent 运行在同一台机器上，通过标准输入输出进行通信。
• 可部署在网络上，通过 HTTP 进行通信。

4.5 MCP 与 AI 模型的关系

• 重要说明：MCP 是一个为 AI 定制的标准，但其本身与 AI 模型无关。
• 职责：MCP 仅负责帮助 Agent 管理工具、资源和提示词，不关心 Agent 具体使用了哪个 AI 模型。

---

5. 整体流程梳理与相互关系

5.1 完整协作流程示例

1. 用户请求：用户（作为 MCP Client 的一部分）向 AI Agent 提问（例如 “我女朋友肚子疼，应该怎么办？”）。
2. Agent 封装：AI Agent 将用户请求包装为用户提示词。
3. 获取工具信息：AI Agent 通过 MCP 协议，从 MCP Server 获取所有可用的 Agent Tool 信息。
4. 发送至 AI 模型：AI Agent 将获取到的 Agent Tool 信息转换为系统提示词格式或 Function Calling 格式，与用户提示词一同打包发送给 AI 模型。
5. AI 模型决策：AI 模型识别到可用的工具（例如 “Web Browse” 网页浏览工具），生成一个调用该工具的请求（可以是普通回复或 Function Calling 格式），意图通过网络搜索答案。
6. Agent 调用工具：AI Agent 接收到工具调用请求后，通过 MCP 协议调用 MCP Server 上的 “Web Browse” 工具。
7. 工具执行与返回：“Web Browse” 工具访问指定网站，将网页内容返回给 AI Agent。
8. Agent 转发：AI Agent 将网页内容转发给 AI 模型。
9. AI 模型生成答案：AI 模型根据网页内容和自身知识，生成最终答案（例如 “多喝热水”）。
10. Agent 展示结果：AI Agent 将最终结果展示给用户。

5.2 关键概念间的关系

• 系统提示词、用户提示词、AI Agent、Agent Tool、Function Calling、MCP、AI 模型等概念并非相互取代，而是像齿轮一样协同工作，共同构成了 AI 自动化协作的完整体系。

二、检索增强生成 (RAG) 架构详解

1. 大模型“幻觉”现象及其解决方案背景

大模型在处理问题时可能出现“幻觉”，即生成与输入问题看似相关但实际脱离上下文的、一本正经的错误回答。将完整文档与问题一并输入大模型可初步解决此问题。然而，当文档内容庞大时，答案可能仅存在于文档的局部或零散信息中。此时，大模型接收完整文档反而容易分散注意力，无法准确捕捉关键信息，导致回答偏离。

2. RAG (Retrieval Augmented Generation) 的核心思想

RAG 旨在解决大模型处理长文档时面临的挑战，其核心在于：在将问题提交给大模型之前，仅从长文档中检索并提取与问题最相关的内容片段，然后将这些相关片段连同用户问题一同提供给大模型，作为其生成回答的上下文。

3. Embedding 模型：判断文本相关性的关键

3.1. 定义与功能

Embedding 模型是一种特殊的神经网络模型，其输入是一段文本（可以是句子或段落），输出是一个固定长度的数值数组（也称为向量或竖组）。

3.2. 与大语言模型的区别

• 输入：两者均接受文本作为输入。
• 输出：
• 大语言模型输出的是生成文本。
• Embedding 模型输出的是一个固定长度的数值数组。
• 目的：
• 大语言模型旨在理解和生成人类语言。
• Embedding 模型旨在将文本转换为数值表示，以便进行数学运算，特别是衡量语义相似度。

3.3. 输出特征与意义

• 固定长度：无论输入文本长短，输出的数组长度均固定。例如，OpenAI 的 Text Embedding 3 Small 模型输出 1536 维向量，Text Embedding 3 Large 模型输出 3072 维向量。
• 有损压缩：可以将输出数组理解为对原始文本信息的有损压缩。信息被浓缩，但其核心语义得以保留。
• 语义相似性：语义相似的文本经过 Embedding 模型处理后，其对应的向量在数学空间中的距离会非常接近。反之，语义差异大的文本，其向量距离则较远。

3.4. 向量空间与距离度量

• 高维坐标系：输出的固定长度数组可被视为一个高维坐标系中的一个点（例如，1536 维或 3072 维）。
• 语义映射：Embedding 模型会将语义上接近的文本映射到向量空间中相互靠近的点。
• 示例：
• “老王爱吃瓜”与“老王喜欢吃瓜”的向量距离会非常近。
• “我也爱 Python”的向量距离会稍远。
• “刚买的飞机被打了”的向量距离会非常远。
• 准确性：高维向量空间能够更准确地表达文本之间的语义距离关系，避免低维空间（如二维）因信息拥挤而导致的失真。

4. RAG 的工作流程

4.1. 文档预处理阶段

在用户提问之前，需对目标文档进行一次性处理：

1. 分块 (Chunking)：

• 将整个长文档切分成多个小片段。
• 切片方法：按字数、按段落、按句子，或采用更复杂的语义分块算法。
• 专业术语：chunking。

1. Embedding 生成：

• 对每个切分后的小片段，使用 Embedding 模型生成对应的固定长度向量。

1. 向量存储与关联：

• 将每个生成的向量与其原始文本片段的对应关系保存起来。
• 向量数据库：专门设计用于存储和检索向量数据，能够高效地查找与输入向量距离最近的数据。这与传统数据库根据精确数值查找记录的模式不同。
• 常见向量数据库：Pinecone, ChromaDB, 以及 PostgreSQL 配合 PG Vector 插件等。

4.2. 用户查询阶段

当用户提出问题时，RAG 系统执行以下步骤：

1. 问题 Embedding：

• 使用与文档预处理时相同的 Embedding 模型，将用户问题转化为一个向量。

1. 向量检索：

• 将问题向量输入到向量数据库中。
• 向量数据库根据距离算法（如余弦相似度）查找与问题向量距离最近的几段文档片段。

1. 上下文构建与提交：

• 将检索到的相关文档片段作为上下文。
• 将此上下文与用户的原始问题一同发送给大语言模型。
• 大语言模型接收到的是强相关内容，从而降低“幻觉”风险，提高回答的准确性。

5. RAG 架构的挑战与改进方向

5.1. 固有缺陷

1. 分块策略的局限性：

• 文章结构各异，单一的分块方法（按字数、段落、句子）难以适配所有场景。
• 关键内容截断：重要信息可能在分块时被不当地切断，导致上下文丢失或指代关系错位。
• 示例：“我是程序员老王，我爱吃瓜。”若切分为两段，“我爱吃瓜”中的“我”将失去与“老王”的指代关系，进而影响相关性判断。
• 再复杂的分块策略也只能尽量减少误伤，无法彻底避免。

1. 缺乏全局视角：

• RAG 侧重于检索与问题直接相关的局部片段。
• 对于需要全局信息汇总的问题（例如“这篇文章中‘我’字共出现了多少次？”），RAG 难以处理，因为此类问题与文章中任何单一语句的相关性都不够强，但与整体文章均有涉猎。

5.2. 改进方案

为弥补上述缺陷，目前涌现出多种改进方案，例如：

• 预处理优化：在分块前进行文本替换，如将所有“我”统一替换为明确的指代对象（“老王”）。
• 大模型参与分块：让大语言模型根据语义自动判断最佳的切分点和方式。

目前尚未出现完美的解决方案，新的想法仍在不断探索中。

6. RAG 的本质

RAG 本质上是一种在有限大模型上下文窗口下的妥协策略。它通过文档切块、筛选、索引等方式进行信息压缩，保留重要信息，舍弃不重要的部分，以期让模型的回答更贴近事实。这种机制能够解决一部分问题，但仍存在诸多未解难题。RAG 是一种过渡性架构，期待未来出现真正意义上突破现有局限的下一代架构。

三、AI编程 Vibe coding 的原理是什么

1、AI编程

（1）原理

程序员提前写好函数

AI agent把函数的名字、用法打包一起给大语言模型

大语言模型就可以告诉agent，你来帮我调用这个函数，传这个参数浏览网页、执行终端命令

（2）AI编程工具，会让大模型以diff的格式来回复修改的内容（那个文件的第几行，需要被替换为新的内容）

AI agent在接收到diff之后，会先检查一下diff里面引用的原始代码跟当前文件是不是一致的。如果不一致，说明模型理解错了上下文，再重新生成

即得到了相对靠谱的AI编程工具

（3）优化（vscode的错误提示）

AI编程工具：读写文件，主动收集上下文信息（比如当前项目的文件结构、用户正在查看的文件名、打开了那些文件、命令行输出的内容、当前的时间）只要不长、不敏感都塞给大语言模型

AI模型更能理解现场，看到的东西和用户一模一样，编程过程自然光就流畅了

2、继续优化——MCP（AI编程机器人的插件系统）

部署前端、配置后台、建立数据库

（2）平台适配问题

这些是提示词，引导适配各个平台

本地

四、知识图谱增强型检索生成 (GraphRAG) 学习笔记

传统检索增强生成 (RAG) 的局限性

传统的 RAG 方法通过将文章切分为文字片段，再将每个片段嵌入为向量并存储于向量数据库中。然而，这种方法存在以下问题：

• 局部细节与全局主题的匹配挑战：

  • 若按句子分块，对于查询 “老王喜欢吃什么”，系统能够轻易检索到 “老王喜欢吃西瓜” 和 “老王也喜欢吃桃子” 等相关度句子。
  • 但若查询 “这篇文章里一共提到了几次西瓜”，由于 “西瓜” 可能分散在多个片段中，没有单一片段能直接回答此问题，传统 RAG 难以统计分散在不同片段的细节，可能导致检索遗漏或错误。
  • 例如，句子 “老王喜欢吃西瓜” 包含 “老王”、“喜欢吃” 和 “西瓜” 三层信息。当问题仅关注 “西瓜” 的提及次数时，传统 RAG 按整段计算相关度，与 “老王” 和 “喜欢吃” 的无关性可能导致整体相关度不高，从而漏掉包含 “西瓜” 的片段。

• 分块粒度的矛盾：

  • 切分过大：容易漏掉细节，难以处理需要统计特定词汇或短语次数的问题。
  • 切分过小（如按词分）：虽能解决统计特定词汇的问题，但会打断信息之间的语义结构和关系，导致无法有效处理如 “老王喜欢吃什么” 这类需要理解实体间关系的问题。

---

GraphRAG：基于知识图谱的解决方案

GraphRAG 利用知识图谱（Knowledge Graph）来解决传统 RAG 在处理复杂查询和语义结构方面的挑战。

1. 知识图谱的基本概念

• Labeled Property Graph (LPG)：一种图结构，包含实体（Nodes）、关系（Edges）和属性（Properties）。
  • 实体：图中的节点，如 “老王”、“西瓜”。
  • 关系：连接实体的边，表示实体间的联系，如 “爱吃”。关系可以附加属性。
  • 属性：实体或关系可以带有的额外信息，如 “老王是一个人”、“西瓜是一个水果”。

---

2. GraphRAG 中知识图谱的构建过程

在大语言模型（LLM）出现之前，构建知识图谱过程复杂且效果有限。LLM 的引入极大地简化了这一过程。

2.1 单个文本片段的知识图谱生成

GraphRAG 为文章中的每个文本片段独立生成一个知识图谱。

• Prompt 设计：

  • 目标明确：例如，“生成‘老王爱吃西瓜’的 LPG”。
  • 核心流程定义：
    • 步骤一：识别实体（Named Entity Recognition, NER）。
      • 从句子中识别出实体，如 “老王” 和 “西瓜”。
      • 实体类型需根据文本内容预先设定（人工设定），GraphRAG 默认使用的实体类型包括：团体、人、位置和事件。
    • 步骤二：识别实体间的关系（Relation Extraction, RE）。
      • 识别实体之间的连接关系，如 “老王” 与 “西瓜” 之间的 “爱吃”。
  • 输出格式定义：明确实体与类型、实体间关系的表示方式（如使用冒号和箭头）。
  • 描述生成：要求 LLM 为每个实体和关系生成简要的文字描述。
  • 警告添加：在 Prompt 中加入警告，指示 LLM 避免编造信息。

• LLM 处理与结果解析：

  • GraphRAG 将包含上述所有要求的 Prompt 发送给 LLM。
  • LLM 根据要求返回结构化文本，其中识别出实体（如 “老王”、“西瓜”）和关系（如 “老王爱吃瓜”）。
  • GraphRAG 解析 LLM 返回的结构化文本以构建知识图谱。

• 信息完整性增强（Data Cleaning / 大模型 PUA）：

  • LLM 生成初步知识图谱后，GraphRAG 会将该图谱连同原文再次发送给 LLM。
  • 提问 LLM 是否存在遗漏信息或需要补充的内容。
  • 若 LLM 指示存在补充，则进行新一轮补充，并再次询问。
  • 此过程循环进行，直至 LLM 确认已无任何可补充的信息。此反复盘问以榨干信息的过程可称为 “Data Cleaning”。
  • 案例：在处理 “西瓜味道甜” 时，如果 “味道” 在提示词中被定义为实体，则 “味道甜” 中的 “味道甜” 也可能被识别为一个实体。

2.2 文章级知识图谱的合并与总结

在所有片段的知识图谱生成完毕后，GraphRAG 会进行合并和总结，以构建一个完整的文章级知识图谱。

• 实体合并：程序自动将名称相同的实体进行合并（例如，合并所有 “老王” 实例和所有 “西瓜” 实例），此过程无需 LLM 参与。
• 描述整合与总结：
  • 在合并过程中，原本分散在不同节点或边上的描述信息也会被一并整合。
  • GraphRAG 将每个被合并的描述信息集合提交给 LLM，请求其生成一段更完整、更通顺的总结性描述。
  • 这段由 LLM 整理的自然语言描述将作为合并后实体的最终描述。
  • 最终结果不仅包含结构清晰的图谱，还附带 LLM 生成的自然语言描述。

2.3 知识图谱与原文的映射维护

GraphRAG 持续维护知识图谱与原文之间的对应关系：

• 对于图谱中的实体，GraphRAG 能够追溯其源自原文的哪些片段。
• 反之，给定一段原文，GraphRAG 也能指出其在知识图谱中对应的实体和关系。
• 此映射关系在后续查询中发挥关键作用。

---

3. 知识图谱的简化与层级结构构建

当文章很长时，生成的知识图谱可能非常庞大复杂，不利于查询。GraphRAG 通过引入层级结构来简化图谱。

• 社区检测与节点合并：

  • 采用如莱顿社区检测（Leiden community detection）等方法，将图中连接紧密的节点合并为一个整体，形成子图。
  • 例如：若图中的四个节点之间边密集，可合并为一个子图。

• 高层次总结描述生成：

  • LLM 利用每个子图中点和边的描述信息，生成一个更高级别的总结性描述，代表该子图的核心含义。
  • 例如：从包含 “老王爱吃瓜”、“老王爱吃桃” 和 “小王爱吃瓜” 的子图中，LLM 可以总结出 “老王爱吃瓜和桃，小王爱吃瓜”。
  • 推理能力：此总结过程不仅仅是简单抽象，LLM 常能推理出原文中未明确提及的信息（如从 “老王爱吃瓜和桃” 与 “小王爱吃瓜” 推理出 “小王不爱吃桃子”）。这体现了知识图谱超越简单文本匹配的理解和思考能力。

• 递归抽象与层级结构：

  • 如果简化后的图谱仍不够简单，可重复上述合并和总结过程，逐层向上抽象。
  • 最终形成一个知识图谱的层级结构：
    • 上层：信息更抽象、更精炼。
    • 下层：更接近原文、更具体细节。

---

4. 知识图谱的索引与查询

构建完成的知识图谱需要转化为可快速检索的索引库。

4.1 索引建立

• Embedding：
  • 将知识图谱中的每个节点、每条边的实体信息和 LLM 生成的总结性描述，都视为一个文字片段。
  • 对这些片段进行 Embedding 处理。
  • 将 Embedding 结果存入向量数据库。
• 原文片段 Embedding：最开始的原文切片也同样进行 Embedding 并存入向量数据库。
• 最终形态：向量数据库中包含知识图谱各层级的嵌入表示和原始文本片段的嵌入表示。

4.2 查询策略

用户问题（如 “老王爱吃什么”）经过 Embedding 转化为向量后，可与向量数据库中的内容进行匹配。查询过程具有高度灵活性。

• 查询范围选择：可选择只查询知识图谱的某一层或某几层，只查询原文，或全部查询。
• GraphRAG 提供的查询策略：
  • 局部搜索 (Local Search)：
    • 起始点：从最底层的知识图谱开始查找。
    • 过程：找出与用户问题最接近的实体。
    • 映射应用：利用知识图谱与原文的映射关系，反向查出这些图谱点和边对应的原文片段，以及它们在哪些上层图谱结构中出现，并识别其相邻的其他点和边。
    • 补充功能：实验性功能 covariate 提供原文片段的文字性总结，可参考 extract covariates 和 claim extractor 文件。
    • LLM 整合：将找到的所有相关图谱点、边的总结性描述、关联的原文片段以及用户问题一同打包发送给 LLM。
    • 优势：擅长处理细节丰富、定位准确的问题。
  • 全局搜索 (Global Search)：
    • 起始点：从图谱的高层开始查找。
    • 过程：逐层向下追溯。
    • 优势：更适合回答抽象度高、全局性强的问题（如 “这篇文章的核心观点是什么”）。

---

5. GraphRAG 的整体评估

• LLM 深度参与：GraphRAG 从构建知识图谱到总结描述，几乎每一步都离不开大语言模型的深度参与。
• 资源消耗：对 LLM 的广泛使用导致其对计算资源（token）的消耗较高。
• 实际效果：根据 Microsoft 论文中的实验数据，GraphRAG 的效果表现良好。
• 运作模式的启示：GraphRAG 的运作过程与人类学习和整合知识的模式具有相似性：从零散的知识点到构建知识图谱，并通过抽象和推理发现新的联系。

GraphRAG 通过在传统 RAG 流程中深度整合大语言模型和知识图谱，有效克服了传统 RAG 在处理复杂语义关系和多粒度信息查询方面的不足，提供了一种更为强大和灵活的知识检索与生成框架。

五、四大关键概念

1. 引言：高级词汇与内容本质

当前技术语境中，存在用 “高级” 词汇指代简单概念的现象（如 “分销” 代指推销、“变现” 代指盈利、“内容创作” 代指内容输出、“私域引流” 代指用户招募、“webcoding” 代指 AI 编写代码）。这类趋势催生了提示词工程（Prompt Engineering）、上下文（Context） 和上下文工程（Context Engineering） 等需深入理解的核心概念。

2. 提示词（Prompt）

2.1 定义

用户发送给大语言模型（LLM）的输入信息，最初大语言模型作为聊天机器人时，用户的问候语（如 “你好”）即为提示词。

2.2 演进与分类

随着 AI 能力发展，提示词使用愈发精细，分为两类：

1. 系统提示词（System Prompt）：用于设定 AI 的角色、行为模式或整体任务，通常由 AI 应用内置，用户一般无法直接修改；部分应用（如 ChatGPT 的 Customize ChatGPT 功能）允许用户自定义偏好并融入系统提示词。
2. 用户提示词（User Prompt）：用户在聊天界面直接输入的对话内容或指令。

2.3 角色设定示例

通过提示词可为 AI 设定特定角色（如系统提示词指示 AI “扮演一个猫娘”），用户后续的提示词将得到符合该设定的回复。

3. 提示词工程（Prompt Engineering）

3.1 定义

通过精心设计系统提示词和用户提示词的组合，引导 AI 返回特定风格、稳定且准确回复的方法与技巧；核心目标是约束 AI 行为，减少错误和意外，使其输出更符合预期。

3.2 常见技巧

3.2.1 行为约束

通过明确要求或设定情境引导 AI 行为，核心方式包括：

• 检查与纠正：AI 处理复杂任务（如数学问题）时，要求其回复前自检答案，提升准确性。
• 情境强调：拒绝回答某些问题时，通过强调事件严重性促使 AI 输出更完整答案。
• Zero Shot：只提出要求，不提供具体示例（如 “回复前检查答案”）。
• Full Shot：在提示词中提供具体示例，帮助 AI 理解并模仿特定格式 / 风格输出（如将正常句子转换为 “猫娘体”，示例：“我们去吃饭”→“我们去吃饭好不好呀喵”），适用于 AI Agent 开发等需稳定返回特定格式字符串的场景。

3.2.2 思维链（Chain of Thought, COT）

引导 AI 逐步思考、分解问题并输出推理过程的技巧，提升复杂问题解决的准确性。

• 原理：大语言模型是概率模型，不擅长精确数学运算；通过要求 AI “分步推理并给出中间结果”，引导其完成逻辑计算。
• 示例：计算 “1 加 2 乘 3”，COT 模式下 AI 会先说明 “先算 2 乘 3 得 6，再算 1 加 6 得 7”，非 COT 模式易给出错误答案。
• 效果：显著提升 AI 解决复杂问题的准确率，尤其适用于早期模型或复杂推理任务；现代网页聊天机器人多内置该功能，用户无需额外输入提示词即可受益。

3.3 本质

通过精心设计提问方式，获取更精准、更符合预期的 AI 回答。

4. 上下文（Context）

4.1 AI 模型记忆的澄清

大语言模型本身不具备记忆功能，每次接收消息都被视为全新、独立的请求。

4.2 记忆的实现机制

连续对话中，AI 的 “记忆” 由 AI Agent 或聊天机器人服务器实现，核心流程：

1. 用户消息发送至 AI Agent / 聊天机器人服务器；
2. 服务器维护完整的历史记录；
3. 收到新消息时，将其附加到历史记录末尾；
4. 将包含所有过往信息的完整历史记录一次性发送给大语言模型。定义：这一被一次性发送给 AI 的完整历史记录，即为 “上下文”。

5. 上下文工程（Context Engineering）

5.1 定义

管理和修改 AI 与用户之间历史记录（上下文）的技巧和方法，旨在确保 AI 在长时间、多步骤的交互中，行为始终符合用户的最初要求。

5.2 复杂性来源：AI Agent

当 AI Agent 引入工具箱并具备调用工具的能力时，上下文管理变得更复杂。

• AI Agent 机制：除传递消息、维护历史记录外，还拥有可供 AI 模型调用的工具。
• 示例（网页浏览功能）：
  1. 用户提问 “猫娘的口头禅是什么”；
  2. AI Agent 将当前上下文和所有可用工具说明打包发送给 AI 模型；
  3. AI 模型决定使用 “浏览网页” 工具，返回特殊指令（tool_code）指示 Agent 搜索；
  4. AI Agent 执行指令，调用网页浏览工具并返回网页内容；
  5. 网页内容被打包成 tool_response 消息，与对应的 tool_code 一起加入上下文；
  6. 更长的上下文再次发送给 AI 模型；
  7. 该过程可能重复多次，导致上下文包含大量中间信息，长度激增。

5.3 挑战

AI Agent 执行复杂任务时，用户仅能在最初通过提示词施加影响；后续大量的 tool_code 和 tool_response（如网页浏览长内容）会迅速增长上下文长度，用户无法及时纠正 AI 行为，导致 AI 易偏离最初目标。

5.4 核心问题

如何在用户无法实时干预 AI 行动时，通过一套程序化规则自动管理和修改上下文，确保 AI 模型在漫长的自主行动中始终记得最初任务，符合用户要求。

5.5 常见管理策略

目前无公认完美解决方案，但业界有多种有效做法：

5.5.1 让 AI 学会记笔记

• 原理：为 AI 模型提供专门的记笔记工具。
• 策略指导：通过系统提示词明确笔记使用策略（如 “行动前拆分任务→写下任务清单→严格按清单执行→完成后记录状态”）。
• 流程示例：AI 收到 “猫娘的口头禅是什么” 的任务后，先头脑风暴生成任务清单，再用笔记工具记录，Agent 将笔记插入上下文开头 / 结尾。
• 关键机制：利用 Transformer 架构对信息开头和结尾敏感的特性，确保核心目标（任务清单、初始提示词）处于显眼位置，不易被 AI 忽略。
• 效果：显著减少 AI 执行复杂任务时偏离轨道的可能性，笔记内容还可扩展为搜索关键信息，便于后续检索。
• 本质：人类通过控制初始提示词指导 AI 记笔记，再通过笔记的显眼位置，间接引导整个 AI 处理流程。

5.5.2 缩短上下文长度

通过多种方式精简上下文，核心方法包括：

1. 直接丢弃旧消息：舍弃过旧消息，仅保留最新消息（限制：初始系统提示词和用户提示词必须保留）。
2. 信息压缩：让 AI 模型总结较旧消息的关键信息，用精炼总结替代原始内容，在保留核心信息的同时压缩长度。
3. 临时向量数据库存储：将过长的 tool_response 存入临时向量数据库（类似 RAG 技术），上下文仅保留 “摘要 + 检索指令”，需时再检索，极大控制上下文长度。
4. 工具返回预处理：AI Agent 在将工具（如网页浏览）返回值提供给 AI 模型前，去除冗余信息（如 HTML 标签），只返回核心内容，从源头减少信息冗余。

6. 核心要点概况

本文核心围绕 AI 时代四大关键概念展开：

1. 提示词：用户 / 系统向 AI 输入的指令，分为系统提示词和用户提示词。
2. 提示词工程：设计提示词组合，约束 AI 行为以获取预期输出，包含行为约束（Zero Shot/Full Shot）和思维链（COT）等技巧。
3. 上下文：为实现 AI “记忆”，由服务器整合的、一次性发送给 AI 的完整对话历史记录。
4. 上下文工程：通过程序化规则管理 / 修改上下文，解决 AI Agent 执行复杂任务时的上下文过长、目标偏离问题，核心策略包括让 AI 记笔记、缩短上下文长度等。

六、Skills 文件夹核心架构与工作流

一、核心文件分类及作用

Skills 文件夹是 AI Agent 完成领域任务的核心载体，分为知识文档类和脚本工具类两类，协同支撑 LLM 完成任务的全流程：

1. 核心知识文档：SKILL.md

• 核心形式：以自然语言为主体，结合 metadata 与文档索引，构建树层级的结构化知识体系。
• 核心作用：
  • 建立任务相关知识的层级索引，实现 “无关信息过滤”，减少任务上下文长度；
  • 为 LLM 提供领域任务的规范化指导、流程逻辑、背景知识等自然语言说明；
  • 是 LLM 进行任务 “发现（Discovery）” 的核心依据。
• 技术实现细节：
  • 文件头部包含 YAML Frontmatter（--- 包裹的区域），作为 metadata 核心载体；
  • 主体为 MarkDown 格式文档，存储任务的详细知识、操作指南、工具说明等内容。

2. 脚本工具类：领域任务工具

• 核心形式：脚本文件、程序片段、MCP（Model Context Protocol）工具等，是 LLM 执行具体任务的 “可操作工具”。
• 核心作用：
  • 补充知识文档的 “操作能力”，扩展 LLM 在特定领域的任务执行能力；
  • 替代纯自然语言指导，让 LLM 直接调用工具完成实际操作（如调用 MCP 工具、执行脚本）。
• 两种存在形式：
  • 静态工具（Hard-coded Tools）：由用户提前编写好的脚本 / 程序，直接嵌入 Skills 体系，供 LLM 静态调用；
  • 动态生成工具（LLM as a Creator）：LLM 基于 SKILL.md 中的信息（库依赖、现有函数），针对当前任务动态生成脚本 / 工具，实现 “按需创建工具”。

二、核心工作流程：Discovery 与 Activation 双阶段

Skills 体系通过 “Discovery（发现）→ Activation（激活）” 两阶段流程，实现知识过滤与工具调用，核心逻辑如下：

1. 第一阶段：Discovery（知识发现）

• 触发时机：系统启动 / 任务初始化时，LLM 首次接收任务需求。
• 核心操作：
  • Agent 仅读取每个 SKILL.md 头部 YAML Frontmatter 中的核心字段（name 名称、description 描述）；
  • 这些数百字符的轻量级 metadata 会被统一注入到 LLM 的 System Prompt 中；
  • LLM 基于这些元信息，判断当前任务涉及哪些 SKILL 文档，筛选出相关的知识文档。
• 核心目的：过滤与任务无关的知识，避免将所有文档内容注入上下文，大幅减少 LLM 需处理的信息总量。

2. 第二阶段：Activation（动态激活）

• 触发时机：Discovery 阶段确认任务与某 SKILL 文档匹配后。
• 核心操作：
  • LLM 向客户端发送指令，动态请求读取匹配到的 SKILL.md 中上万字的具体 MarkDown 内容；
  • 若任务涉及工具调用，LLM 会同时激活对应的脚本工具（静态工具直接调用，动态工具则先生成再调用）；
  • 结合读取的知识文档与调用的工具，完成具体任务。
• 核心目的：仅在需要时加载详细知识，实现 “按需加载、精准调用”，提升任务执行效率。

三、核心概念补充

1. Metadata（元数据）

• 技术表现：SKILL.md 文件头部 YAML 格式的 Frontmatter（--- 与 --- 之间的内容）；
• 核心内容：包含 SKILL 文档的 name（唯一标识）、description（任务描述）等关键信息，是 Discovery 阶段的唯一依据。

2. 核心逻辑价值

• 分层解耦：将 “知识描述（SKILL.md）” 与 “工具执行（脚本 / MCP）” 分离，知识负责 “指引”，工具负责 “执行”，体系更清晰；
• 轻量化检索：Discovery 阶段仅读取轻量 metadata，避免上下文膨胀；Activation 阶段仅加载必要知识，精准匹配任务；
• 动态扩展：支持 LLM 动态生成工具，无需用户提前编写所有工具，适配多样化任务场景。