AI 编程 | 概念全景梳理
因为自己不太懂 AI 相关的一些概念，问了问 AI，看了些文章，然后整理成这篇笔记。本文主要讲 AI 相关的核心概念，以及从用户发出需求开始，背后究竟发生了哪些事。定位偏基础，适合前端 / 全栈工程师建立 AI 工程视角。如有错误，欢迎各位看官不吝指教！🙏🏻
一、先看历史：技术是怎么一步步走到今天的
理解现在，得先知道来路。
很多人第一次接触这些概念时，会以为"向量数据库催生了大模型"------其实顺序正好相反，是大模型的爆火让向量数据库找到了用武之地。把时间线梳理清楚，后面每个概念"为什么存在"就自然而然想明白了。
┌─────────────────────────────────────────────────────────────────────────────┐
│ AI 技术发展时间线 │
├──────────┬──────────────────────────────────────────────────────────────────┤
│ 2017 │ Google 发布论文《Attention Is All You Need》 │
│ │ → Transformer 架构诞生，奠定现代 LLM 的基石 │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ 2018~20 │ BERT（Google）、GPT-1/2/3（OpenAI）相继问世 │
│ │ → 预训练 + 微调范式确立，涌现能力（Emergent Ability）首次出现 │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ 2022.11 │ ChatGPT 发布，LLM 进入大众视野 │
│ │ → 开发者开始大量接入 LLM API，工程化需求爆发 │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ 2022~23 │ 向量数据库（Pinecone / Milvus / Chroma）大规模普及 │
│ │ RAG 范式兴起，解决 LLM 知识过期 & 幻觉问题 │
│ │ LangChain / LlamaIndex 等 Agent 框架相继出现 │
│ │ Cursor 发布（Anysphere，2023），AI 编码工具元年 │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ 2024.11 │ Anthropic 发布 MCP 协议（Model Context Protocol） │
│ │ → 工具调用标准化，Agent 生态走向统一 │
├──────────┼──────────────────────────────────────────────────────────────────┤
│ 2025 │ Claude Code 发布（Anthropic，终端 CLI Agent） │
│ │ → Agent 落地加速，多 Agent 协作成为新议题 │
└──────────┴──────────────────────────────────────────────────────────────────┘用一句话把上面的链条串起来：
LLM 是地基 → RAG 给 LLM 装上长期记忆 → MCP 让工具调用有了统一标准 → Agent 把大脑、记忆和手脚整合成一个自主系统 → Skills / AGENTS.md 给 Agent 装上了项目规则手册
二、核心概念逐个拆解
2.1 LLM --- 大语言模型
LLM（Large Language Model） 是基于 Transformer 架构、经过海量文本预训练的大规模语言模型，代表产品有 GPT-4、Claude、Gemini。
它的本质能力是预测下一个 token------通过对海量人类文本的学习，把语法、逻辑、常识都压缩进数百亿个神经网络参数（Weights）里。这些参数在训练完成后就固定下来，模型"出厂"后不会自动更新。
交互模式极其简单：
┌─────────────┐ ┌──────────────────┐ ┌─────────────┐
│ Prompt In │ ────► │ LLM 推理引擎 │ ────► │ Text Out │
│ （输入） │ │ 理解 · 推理 · 生成│ │ （输出） │
└─────────────┘ └──────────────────┘ └─────────────┘把 LLM 理解成大脑是一个很贴切的比喻------它能理解你说的话、写代码、做逻辑推理。但光有大脑还不够，它不能主动翻文件、执行命令、访问网络，这些能力需要外部系统配合，这也是 RAG、MCP、Agent 存在的根本原因。
LLM 是如何理解自然语言的？
LLM "理解"语言并非真的像人类一样读懂含义，而是一套数学流程：将文字逐步转化为高维数值，再通过注意力机制捕获词语之间的关联。整个过程分为四步：
① 分词（Tokenization）
┌─────────────────────────────────────────────────┐
│ 原始文本："帮我写一个 Vue 组件" │
│ ↓ Tokenizer（分词器） │
│ Token 序列：["帮", "我", "写", "一个", "Vue", │
│ "组", "件"] │
│ 每个 Token 映射到一个整数 ID │
└─────────────────────────────────────────────────┘
② 向量化（Embedding）
┌─────────────────────────────────────────────────┐
│ 每个 Token ID → 高维浮点向量 │
│ "Vue" → [0.23, -0.81, 0.44, ...]（768~4096 维） │
│ 此时每个词有了"位置"，但彼此还是孤立的 │
└─────────────────────────────────────────────────┘
③ 注意力计算（Self-Attention）--- Transformer 核心
┌─────────────────────────────────────────────────┐
│ 模型对每个 Token 计算它与其他所有 Token 的 │
│ "相关程度"（注意力权重） │
│ │
│ "组件" 会把注意力集中到 "Vue" 和 "写" 上 │
│ → 语义从孤立词变为"语境中的词" │
│ │
│ 多头注意力（Multi-Head Attention）： │
│ 同时从多个维度捕获语义、句法、指代等不同关系 │
└─────────────────────────────────────────────────┘
④ 自回归生成（Auto-regressive Generation）
┌─────────────────────────────────────────────────┐
│ 基于以上所有上下文，预测"下一个 Token"的概率分布 │
│ → 采样 / 取最高概率 → 追加到序列 → 再次预测 │
│ → 循环直到生成 <EOS>（结束符） │
└─────────────────────────────────────────────────┘💡 LLM 本质上在做的事是：从海量文本中学习"哪些词在什么语境下应该出现在一起"，然后在推理时根据上下文，给出统计上最合理的续写。它没有主观理解，但因为训练数据足够大，涌现出了很强的"仿理解"能力。
LLM 的固有局限：
| 缺陷 | 说明 |
|---|---|
| 知识截止（Knowledge Cutoff） | 训练数据有时间截止点，对最新事件一无所知 |
| 幻觉（Hallucination） | 可能生成看起来合理但实际错误的内容 |
| 领域知识不足 | 企业私有文档、内部代码库完全不了解 |
| 上下文窗口有限 | 单次推理能处理的文本量存在上限 |
| 推理成本高 | 按 token 计费，长对话成本显著 |
正是这些局限，推动了后续一系列工程技术的诞生。
2.2 Prompt --- 提示词
Prompt 就是你发给模型的输入内容。它不只是一句话，而是模型"看到"的全部信息的总称------包括角色定义、背景上下文、任务指令和输出格式要求。
┌──────────────────────────────────────────────────────┐
│ 一个完整的 Prompt │
├─────────────────────┬────────────────────────────────┤
│ System Prompt │ 角色定义、能力边界、输出格式 │
│ （系统提示词） │ 行为约束、禁止项 │
├─────────────────────┼────────────────────────────────┤
│ History │ 历史对话记录（多轮上下文） │
│ （对话历史） │ │
├─────────────────────┼────────────────────────────────┤
│ Context │ RAG 检索到的相关文档片段 │
│ （增强上下文） │ 当前项目代码 / 文件内容 │
├─────────────────────┼────────────────────────────────┤
│ User Query │ 用户当前的问题 / 需求 │
│ （用户输入） │ │
└─────────────────────┴────────────────────────────────┘模型给出的答案质量，很大程度上取决于 Prompt 的质量，这也是「提示词工程（Prompt Engineering）」这个方向存在的原因。同一个需求，描述得越清晰、上下文越充分，模型的输出就越准确。
2.3 Token 与 Context Window
Token
Token 是模型内部处理文本的最小单位，可以理解为"子词"。不同模型的 tokenizer 分词规则有差异，大致参考：
- 英文单词：
running≈ 1 token - 中文汉字：1 个汉字 ≈ 1~2 token（视 tokenizer 而定）
- 常见短语可能被合并为 1 个 token
💡 费用计算 = 输入 token 数 + 输出 token 数 ，发送的 Prompt 和模型返回的文本都算在内。可用
tiktoken（OpenAI）等工具库在本地预估消耗。
Context Window（上下文窗口）
上下文窗口是模型单次推理能"看到"的最大 token 数量，等同于它的工作记忆------不仅仅是当前这一条消息，而是所有塞进去的内容总和：
┌──────────────────────────────────────────────────────────────────────┐
│ Context Window │
│ │
│ System │ 对话 │ RAG 检索 │ 工具返回 │ 当前输入 │ 输出 │
│ Prompt │ 历史 │ 上下文 │ 结果 │ │ 预留 │
│ │
│ ◄──────────────── 最大 Token 限制（不同模型不同）────────────────► │
└──────────────────────────────────────────────────────────────────────┘主流模型上下文窗口参考（2025 年）：
| 模型 | 上下文窗口 |
|---|---|
| GPT-4o | 128K tokens |
| Claude 3.5 Sonnet | 200K tokens |
| Claude 3.7 Sonnet | 200K tokens |
| Gemini 1.5 Pro | 1M tokens |
| Gemini 2.0 Flash | 1M tokens |
当对话内容超出窗口上限时，Agent 通常会采用两种策略兜底：
- 滑动窗口（Sliding Window）：丢弃最早的对话轮次，只保留最近 N 条
- 自动摘要（Auto Summary）：把早期对话压缩成摘要，保留语义而非原文
2.4 Vector Embeddings --- 向量嵌入
向量嵌入（Vector Embeddings） 是把文本、图片等非结构化内容，转换为一组高维数值数组的过程。这个数组就是"向量"，由 Embedding 模型生成，维度一旦确定就固定不变。
为什么需要向量？因为计算机无法直接比较两段文字的"语义相似度"，但可以计算两个向量的距离（余弦相似度 / 欧氏距离）。Embedding 的核心意义就是：把语义相似的内容，映射到向量空间中相近的位置。
文本空间（无法直接比较语义） 向量空间（可以度量距离）
┌──────────────────────┐ ┌────────────────────────────────┐
│ "今天天气真好" │ │ [0.82, -0.31, 0.56, ...] ◄──┼─ 距离近
│ "阳光明媚的一天" │ Embed ► │ [0.79, -0.28, 0.61, ...] ◄──┼─ 语义相似
│ "股票大跌了" │ │ [-0.44, 0.91, -0.20, ...] ◄──┼─ 距离远
└──────────────────────┘ └────────────────────────────────┘💡 向量的每一个维度本身没有具体含义，是神经网络在训练过程中自动学习到的抽象语义特征，维度数由 Embedding 模型决定（固定不变，如 text-embedding-3-small 输出 1536 维）。
2.5 Vector Database --- 向量数据库
向量数据库（如 Milvus、Pinecone、Qdrant，本地可用 Chroma）是专门为高效相似度检索而设计的存储层，支持 ANN（近似最近邻）算法，能在毫秒级别从海量向量中找到最相似的 K 个结果。
它的存储结构很简洁，核心就三个字段：唯一 ID、向量数组、原始内容或元数据。
json
// 基础结构（以 Qdrant 字段命名为例）
{
"id": "doc_12_chunk_3",
"vector": [0.012, -0.88, 0.34, ...], // Embedding 模型生成的高维向量
"payload": {
"text": "LangChain 是一个 LLM 应用框架...",
"source": "langchain.pdf",
"chunk_index": 3,
"created_at": 1710000000
}
}💡 存储策略：小文本直接放在 payload 里；大文本存关系型数据库，向量库只存 ID 引用，避免单条记录过大影响检索性能。
向量数据库能存哪些东西：
| 类别 | 示例 |
|---|---|
| 文档知识库 | 技术文档、产品手册、法律条文 |
| 对话历史 | 用户历史对话的语义摘要 |
| 企业内部知识 | 内部 Wiki、会议记录、邮件摘要 |
| 代码库 | 函数、类的代码块及注释 |
| 网页内容 | 爬取并切块后的网页段落 |
| 用户画像 | 用户偏好、行为模式的向量表示 |
| 多模态内容 | 图片 / 视频的文本描述向量 |
数据库膨胀的管理策略：
随着时间推移，向量数量会持续增长，常用三种策略控制规模：
- 滑动窗口（Sliding Window）：只保留最近 N 天的数据，到期删除
- 重要性降权（Importance Decay）：旧向量降低检索权重而非直接删除，保留但弱化影响
- 分层存储（Tiered Storage）：近 7 天热存储、7~30 天温存储、30 天以上归档，按访问频率分层
此外，随着数据量增大，可通过分片、倒排索引、聚类等技术解决性能扩展问题------这不是简单的二维坐标检索，而是有一整套工程体系支撑的。
2.6 RAG --- 检索增强生成
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种独立的技术范式，可以单独使用（比如企业知识库问答系统），也常作为 Agent 的检索模块集成。它的核心思路是：先检索，再生成------在调用 LLM 推理之前，先从外部知识库拉取相关内容，一起塞进 Prompt，让模型"有据可查"地回答，而不是靠训练时的记忆凭空生成。
RAG 分为两个阶段，时序上完全分离：
━━━━━━━━━━━━━━━━━━━━━━ 阶段一：知识库构建（离线，一次性） ━━━━━━━━━━━━━━━━━━━━━━
原始数据源 文档解析 Chunk 切分
┌──────────┐ ┌──────────┐ ┌──────────┐
│ PDF / MD │ │ 文字 │ │ 段落切块 │
│ 代码/Wiki │ ─────► │ 提取 │ ─────► │(~512 tok)│
└──────────┘ └──────────┘ └────┬─────┘
│
Embedding 模型向量化
│
▼
┌──────────┐
│ Vector DB│ ← 写入，离线完成
└──────────┘
━━━━━━━━━━━━━━━━━━━━━━ 阶段二：知识查询（在线，每次请求） ━━━━━━━━━━━━━━━━━━━━━━
用户提问 临时向量化（只读） 相似度检索 精排
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│"如何使用 │ │ Embedding│ │ top-k │ │Reranker │
│ Vue 3 │ ─────► │（不写入 │ ─────► │ 相关文档│ ─────► │ 精排打分 │
│ 响应式？"│ │ DB） │ │ │ └────┬─────┘
└──────────┘ └──────────┘ └──────────┘ │
┌────────▼───────┐
│ 拼入 Prompt │
│ 送给 LLM 生成 │
└────────────────┘💡 在线查询阶段，用户问题会被临时向量化用于检索，这个向量不会写入数据库，只是一次性的检索 key。写入操作仅发生在离线的构建阶段。
Top-K 文档是什么？
在相似度检索这一步，系统会把用户问题的向量与知识库中所有文档 Chunk 的向量逐一比较相似度（余弦相似度等），然后按相似度从高到低排序，取出得分最高的前 K 个文档片段，这就是 Top-K 文档。
向量数据库中有 10000 个 Chunk
─────────────────────────────────────────────────────
相似度排名 │ Chunk 内容摘要 │ 相似度得分
─────────────────────────────────────────────────────
#1 │ Vue 3 响应式原理 ref/reactive │ 0.94
#2 │ Vue 3 Composition API 入门 │ 0.91
#3 │ watchEffect 与 watch 的区别 │ 0.87
··· │ ··· │ ···
#10000 │ CSS Grid 布局教程 │ 0.03
─────────────────────────────────────────────────────
Top-K（K=3）→ 取 #1 #2 #3，拼入 Prompt 交给 LLMK 值是一个可调参数，通常取 3~10。K 越大，检索到的上下文越丰富，但也会消耗更多 Context Window 空间并引入噪音；K 越小，精准度高但可能遗漏关键信息。
实际工程中通常还会在 Top-K 后接一个 Reranker（精排模型），对这 K 个候选片段做二次评分重排，进一步提升最终送入 LLM 的文档质量。
在 AI 编码场景下，RAG 的"检索"就是：接收到你的需求后，扫描整个项目索引，找到相关的组件、类型定义和配置文件，作为上下文一起发给模型------这是模型能"理解你的项目"的根本原因。
2.7 MCP --- 模型上下文协议
MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 于 2024 年 11 月发布的开放协议，本质是定义了一套标准：工具如何向模型声明自己的能力，模型如何通过统一接口调用这些工具。
没有 MCP 之前，每个编辑器都要自己实现一套"读文件、执行命令、调 API"的逻辑，彼此不通用。有了 MCP，就像有了 USB 接口标准------任何工具只要实现了 MCP Server，任何支持 MCP 的 Agent 就能直接调用，无需重复开发。
MCP = 工具 / 系统 与 LLM 之间的统一通信标准MCP 三层架构
┌───────────────────────────────────────────────────────────────────┐
│ Host（主机） │
│ 运行环境 Cursor / VS Code / Claude Code │
│ · Agent 的载体，用户交互的 UI 界面 │
│ · 协调和管理多个 Client 实例 │
└───────────────────────────┬───────────────────────────────────────┘
│ 管理（1 Host : N Client）
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ...
│ Client A │ │ Client B │
│ 大模型的"网卡" │ │ 大模型的"网卡" │
│ · 转发 tool_call│ │ · 转发 tool_call│
│ · 回传执行结果 │ │ · 回传执行结果 │
└────────┬─────────┘ └────────┬─────────┘
│ 1:1 连接 │ 1:1 连接
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Server A │ │ Server B │
│ 文件系统插件 │ │ GitHub 插件 │
│ read/write_file │ │ clone/push/PR │
└──────────────────┘ └──────────────────┘通信协议（JSON-RPC 格式）：
json
{
"method": "tools/call",
"params": {
"name": "write_file",
"arguments": { "path": "src/app.js", "content": "..." }
}
}MCP 支持两种传输机制：
| 传输方式 | 适用场景 | 特点 |
|---|---|---|
| Stdio（标准输入输出） | 本地进程通信 | 性能最优，无网络开销，通常 1:1 服务单个 Client |
| HTTP / SSE（流式） | 远程工具调用 | 支持多 Client 并发连接，适合云端部署的 MCP Server |
MCP Server 支持的工具能力（举例）：
文件系统 read_file(path) / write_file(path, content) / list_dir(path)
终端执行 run_shell(cmd) ← 必须在安全隔离环境下运行
Git 操作 clone / commit / push / create_pr
HTTP 请求 http_get(url) / headless 浏览器（处理动态页面）
向量检索 vector_search(query_embedding, top_k)
数据库 直接连接 DB 驱动执行 SQL
CI/CD 调用云 provider SDK（aws cli、gcloud 等）
代码执行 code_executor(code, language)双向工作流（Sampling）： MCP 还支持"反向请求"------Server 可以发起对 LLM 的调用请求，实现更复杂的递归 Agent 行为：
正向（工具调用）： Host ──► Client ──► Server（执行工具）
反向（Sampling）： Server ──► Client ──► Host ──► LLM（发起 LLM 推理）实现 MCP Server 常用的工具库：
- 系统操作 ：
subprocess/child_process（执行 Shell），os/pathlib（文件系统） - HTTP ：
requests/httpx（Python），axios/fetch（JavaScript） - 云服务 ：
boto3（AWS）、google-cloud-*（GCP）、paramiko（SSH） - 浏览器自动化：Playwright、Puppeteer、Selenium
2.8 Guardrails --- 护栏
高速公路的护栏是为了防止车辆偏离轨道。AI 里的护栏，是为了防止模型的输入和输出偏离安全、合规、准确的边界。它既是概念，也是工程上的独立模块，通常集成在 Agent 或平台层中。
Guardrails 覆盖整条链路，从用户输入到最终输出都有介入：
用户输入
│
▼
┌─────────────────────────────────────────────────────┐
│ 输入层（pre-prompt） │
│ 敏感词过滤 · 注入攻击检测 · 格式校验 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 工具声明层 │
│ 白名单约束可调用工具 · 参数类型校验 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 模型交互层（runtime） │
│ tool_call 权限校验 · 高危命令二次确认 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 后处理层（post-generation） │
│ 规则匹配 · 合规检查 · 敏感数据过滤 │
└──────────────────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 审计层 │
│ 记录所有调用日志，支持人工审计与回滚 │
└─────────────────────────────────────────────────────┘按作用分类（参考 McKinsey 框架）：
| 类型 | 作用 |
|---|---|
| 适当性（Appropriateness） | 检测内容是否有毒、有害、带偏见，拦截不当内容 |
| 幻觉（Hallucination） | 确保生成内容不含事实错误或误导性信息 |
| 合规性（Regulatory-compliance） | 验证内容是否符合行业监管要求 |
| 对齐（Alignment） | 确保输出不偏离用户的原始意图 |
| 验证（Validation） | 检查内容是否满足特定标准，可触发修正循环 |
四个核心组件：
- Checker（检查器）：扫描 AI 生成内容，检测错误并标记问题
- Corrector（校正器）：Checker 发现问题后，对输出进行润色和修正
- Rail（轨道）：管理 Checker 与 Corrector 的交互循环，未达标则反复触发修正
- Guard（守卫）：统筹协调以上三者，汇总结果，输出最终内容
2.9 AI Agent --- 智能体
前面提到，LLM 本身只能"问答"，它不会主动做事。AI Agent 就是在 LLM 之上构建的自主系统，赋予了模型"主动推进任务"的能力。
AI Agent = LLM（大脑）
+ Memory（记忆） ← Context Window（短期）+ Vector DB（长期）
+ Tool Layer / MCP（手脚）← 文件读写、终端、网络、Git...
+ Planning & Execution ← 拆解目标、循环执行、自我纠错一个典型的例子：输入"帮我实现用户登录逻辑"
用户输入："帮我实现用户登录逻辑"
│
▼
① 感知 & 理解：读取项目结构，了解技术栈和现有代码
│
▼
② 规划：拆解任务步骤 → 选择需要调用的工具
│
▼
③ 执行工具调用：
read_file("src/router/index.ts") → 了解现有路由结构
read_file("src/types/user.ts") → 了解用户类型定义
write_file("src/api/auth.ts", ...) → 生成认证 API 层
write_file("src/views/Login.vue", .) → 生成登录页面
│
▼
④ 观察 & 反馈：
run_shell("npm run build") → 验证编译
→ 发现类型错误 → 自动修复 → 再次验证
│
▼
⑤ 任务完成 or 继续下一轮循环这个 "感知 → 规划 → 执行 → 观察 → 反馈" 的循环，叫做 ReAct（Reasoning + Acting）框架，是 Agent 行动的基本模式，可能循环多轮直到任务完成或触发终止条件。
Agent 内部模块结构：
┌────────────────────────────────────────────────────────────────────┐
│ Agent Runtime │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌──────────────────────┐ │
│ │ Planner │ │ Router │ │ Memory │ │
│ │ │ │ │ │ │ │
│ │ · 分解任务 │ │ · 直接回答？ │ │ · short-term │ │
│ │ · 制定步骤 │ │ · 需要 RAG？ │ │ (Context Window) │ │
│ │ · 选择工具 │ │ · 需要工具？ │ │ · long-term │ │
│ └───────────────┘ └───────────────┘ │ (Vector DB / 文件) │ │
│ └──────────────────────┘ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Tool Manager │ │
│ │ · 维护可用工具列表（tool schema） │ │
│ │ · 通过 MCP Client 发起工具调用，接收执行结果 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Prompt Builder │ │
│ │ System Prompt + 对话历史 + RAG 文档 + 工具结果 + 用户输入 │ │
│ └─────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────┘Agent 目前已具备多模态能力，能查看图片内容、读取代码截图。音频、视频等模态的支持也在持续推进中。
2.10 Skills --- 技能规范文件
Skills 是一种「技能规范说明集」，让 AI 编程助手理解某个技术、规范、工具或最佳实践的正确使用方式。
一个 Skill 通常是一个格式化的 Markdown 文件，包含两个核心部分：
- 元数据（Metadata）：定义 Skill 的名称、版本、适用的文件范围（Patterns）等
- 指令内容（Instructions）：描述编码标准、最佳实践、API 正确用法及需规避的坑
说人话就是：当我写 Vue 项目时，你就参考我给的 Vue 规则集（API、写法推荐、最佳实践）来给方案，而不是靠训练时学到的旧知识。
Skills 的流行起源于社区开源项目 antfu/skills（由 Vue 核心团队成员 Anthony Fu 发起），将规则文件打包成 npm 包，方便复用别人的规范，而不用每个人都从头搭建。
安装使用：
shell
# 安装 vue、vite、vue-best-practices 三个 skill
npx add-skill antfu/skills --skill vue --skill vite --skill vue-best-practices安装时会交互式询问你要支持哪些 Agent，根据选择生成对应目录：
shell
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ── always included ──────────────
│ • Amp • Codex • Cursor • Gemini CLI
│ • GitHub Copilot • Kimi Code CLI • OpenCode
│
│ ── Additional agents ─────────────────────────
│ ❯ ● Claude Code (.claude/skills)
│ ○ Cline (.cline/skills)
│ ○ Continue (.continue/skills)
│ ↓ 24 more
└安装后生成的目录结构：
shell
.agents/skills/ ← 通用目录，Cursor / Copilot / Codex / Gemini CLI 等都读这里
├── vue/
│ ├── references/
│ │ ├── core-new-apis.md
│ │ ├── advanced-patterns.md
│ │ └── script-setup-macros.md
│ ├── GENERATION.md
│ └── SKILL.md
└── vite/
├── references/
│ └── core-features.md
└── SKILL.md
.claude/skills/ ← Claude Code 专用目录（部分 Agent 有独立目录）可以把 Skill 理解为：给 Agent 的任务级 playbook / 工作手册------告诉它"在这个项目里，你应该怎么写代码"。
2.11 其他词汇
Vibe Coding（氛围编程）：以自然语言描述意图、由 AI 自动生成代码、开发者主要负责审查和引导的编程方式。强调人机协作中的"方向感"，而非逐行手写。
Multimodal（多模态）：处理多种数据类型（文本、图像、音频、视频）的能力。GPT-4o、Claude 3、Gemini 均已支持图文混合输入。
三、项目中的上下文配置文件
这些文件的共同目的只有一个：为 Agent / 模型提供额外上下文、规范和快速索引，减少模型反复推断、猜测项目规则的成本。
┌────────────────────────────────────────────────────────────────┐
│ 项目配置文件 · 作用层级 │
├────────────────────┬───────────────────────────────────────────┤
│ llms.txt │ 三方库级别：告知 AI 哪里找最新文档 │
├────────────────────┼───────────────────────────────────────────┤
│ AGENTS.md │ 项目级别：构建命令、规范、约定 │
├────────────────────┼───────────────────────────────────────────┤
│ CLAUDE.md │ 工具级别：特定 Agent 的偏好配置 │
│ .cursorrules │ │
├────────────────────┼───────────────────────────────────────────┤
│ .agents/skills/ │ 技术栈级别：框架 API 规范和最佳实践 │
└────────────────────┴───────────────────────────────────────────┘AGENTS.md
专门给 AI 编码 Agent 看的项目说明文件，类似"AI 专用 README"，聚焦机器执行的细节：构建命令、测试流程、代码风格规范、commit message 格式等。Agent 启动时会优先读取，避免反复询问或靠训练知识猜测项目约定。
可分层嵌套使用------在 monorepo 的子包目录里也可以放 AGENTS.md，Agent 会优先使用距当前编辑文件最近的那一个。
llms.txt / llms-full.txt
为大语言模型优化的依赖库文档索引文件，以简洁 Markdown 格式提供结构化清单，告知 AI 哪里能找到该库的 API 文档、最佳实践和核心架构说明。
当你的项目用到某个库时，AI 会读取该库的 llms.txt，确保使用的是最新 API 而非训练数据里的旧版本。（还记得 Tailwind CSS 因流量经济考虑拒绝添加 llms.txt 的 PR 吗？😂）
CLAUDE.md / Copilot Instructions
针对特定 Agent 的默认上下文和指令集，用于持久化用户的偏好配置------比如"所有组件必须用 <script setup> 语法"、"禁止使用 any 类型"等。
.cursorrules / .skills
工具特有的规则文件，在特定环境下约束 Agent 的自动行为。例如 .cursorrules 可强制要求"使用 TypeScript 严格模式"、"禁止直接操作 DOM"、"组件必须放在 src/components 目录下"。
四、Agent 完整交互流程
掌握了前面所有概念后，来看一次完整的 Agent 执行过程究竟是什么样的。
前提：向量数据库已完成离线知识库构建；Agent 启动时已将 AGENTS.md 内容注入 System Prompt；MCP Client 已初始化并与各 MCP Server 建立连接。
Agent 上下文来源优先级（从高到低）：
① 对话 Context Window ------ 实时输入，权威度最高
② System Prompt / AGENTS.md ------ 启动时注入，规定基础行为
③ RAG 检索结果 ------ 按需召回，补充领域知识
④ Vector DB 长期记忆 ------ 历史语义索引
⑤ 模型训练参数 ------ 静态知识，兜底完整执行流程（Mermaid 流程图）：
核心循环：⑤ LLM 推理 → ⑥ 工具执行 → ⑦ 结果回传 可能循环多轮，直到任务完成或触发终止条件（最大步数 / 超时）。简单问答和代码审查路径会跳过 ③④ 步，直接进入 ⑤。
五、主流工具横向对比
这些工具都内置了 Agent，但各有侧重：
| 工具 | 类型 | 核心特点 |
|---|---|---|
| Cursor | IDE（基于 VS Code） | Anysphere 公司，2023 年发布。理解完整项目上下文，Agent 模式可自主完成多步任务 |
| Windsurf | IDE（基于 VS Code） | Codeium 公司出品。内置 Cascade Agent，实时感知编辑器状态（光标位置、控制台信息） |
| GitHub Copilot | 插件 | 最早的 AI 编程助手，主要做代码补全建议，支持 VS Code、JetBrains 等主流编辑器 |
| Claude Code | 终端 CLI | Anthropic，2025 年发布。纯终端 Agent，深度感知未打开的文件，完整支持 MCP 和 Skills |
社区开源项目：
| 项目 | 定位 |
|---|---|
| OpenCode | 开源终端 Agent，类 Claude Code，model-agnostic，支持多种 LLM 后端 |
| OpenHands | 开源"全栈 AI 工程师"，内置 Docker 沙盒隔离，面向团队 / 企业的编码 Agent 平台 |
| OpenClaw | 面向个人的全能自动化助理，支持通过聊天 / 短信 / WhatsApp 触发日常任务自动化 |
六、生态全景总结
读完全文，把各个部分的分工再整理一遍：
┌────────────────────────────────────────────────────────────────────┐
│ AI 工程生态 · 各层分工 │
├─────────────────┬──────────────────────────────────────────────────┤
│ LLM │ Reasoning --- 理解语言、逻辑推理、生成内容 │
├─────────────────┼──────────────────────────────────────────────────┤
│ RAG │ Knowledge --- 外挂知识库，突破知识截止和幻觉限制 │
├─────────────────┼──────────────────────────────────────────────────┤
│ MCP │ Tool Interface --- 标准化工具调用，扩展执行能力 │
├─────────────────┼──────────────────────────────────────────────────┤
│ Agent │ Planning + Execution --- 自主拆解任务并推进完成 │
├─────────────────┼──────────────────────────────────────────────────┤
│ Skills / │ Context + Rules --- 注入项目规范，约束生成行为 │
│ AGENTS.md │ │
├─────────────────┼──────────────────────────────────────────────────┤
│ Guardrails │ Safety --- 输入输出双向防护，保障安全与合规 │
└─────────────────┴──────────────────────────────────────────────────┘它们之间的依赖关系，形成一个完整的闭环：
LLM（推理引擎）
│
┌────────────────┼────────────────┐
▼ ▼ ▼
RAG MCP Guardrails
检索知识 执行工具 安全防护
(Vector DB) (Tool Server)
│ │
└────────────────┘
│
▼
Agent
协调以上一切，主动推进任务
│
┌────────┴────────┐
▼ ▼
Skills AGENTS.md
框架规范 项目约定结语
AI 工程的本质，是把 LLM 的推理能力 ，通过一系列工程组件放大成自主行动能力。
我们正在经历的不只是工具的更新------更像是一次开发范式的迁移：从人写每一行代码，到人描述意图、AI 执行实现，再到 AI 自主规划、人审查结果。
随着 Agent 越来越成熟，机器人（不只是人形机器人，还有工业机械臂、农业辅助器械）越来越智能，AI 在人类重复性工作中的参与度也会越来越高。带来的是效率还是新的复杂性？可能两者都有。但这大概率是接下来的方向。