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）
┌─────────────────────────────────────────────────┐
│ 原始文本："今晚想吃点清淡的" │
│ ↓ Tokenizer（分词器） │
│ Token 序列：["今晚", "想", "吃", "点", │
│ "清", "淡", "的"] │
│ 每个 Token 映射到一个整数 ID │
└─────────────────────────────────────────────────┘
② 向量化（Embedding）
┌─────────────────────────────────────────────────┐
│ 每个 Token ID → 高维浮点向量 │
│ "清淡" → [0.23, -0.81, 0.44, ...]（768~4096 维）│
│ │
│ 注意，这里不是"找相似文档"（那是 RAG 的逻辑） │
│ 向量只是为下一步注意力计算做数学准备 │
└─────────────────────────────────────────────────┘
③ 注意力计算（Self-Attention）— Transformer 核心
┌─────────────────────────────────────────────────┐
│ 模型对每个 Token 计算它与其他所有 Token 的 │
│ "相关程度"（注意力权重） │
│ │
│ "清淡" 会把注意力集中到 "吃" 和 "今晚" 上 │
│ → 理解这不是"性格清淡"，而是"口味清淡" │
│ │
│ 多头注意力（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
中国发展高层论坛2026年会上，国家数据局局长刘烈宏也给出了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 限制（不同模型不同）────────────────► │
└──────────────────────────────────────────────────────────────────────┘
主流模型上下文窗口参考（2026年年初）：
| 模型类别 | 模型名称 | 上下文窗口 (Context Window) | 备注 |
|---|---|---|---|
| OpenAI | GPT-5.2 (Garlic) | 400K tokens | 相比 GPT-4o 提升了 3 倍以上，输出长度大幅增至 128K |
| GPT-5 | 400K tokens | 2026 标准旗舰版，强化了 Agent 执行能力 | |
| Anthropic | Claude Opus 4.6 | 1M tokens (Beta) | Opus 级模型首次支持百万级上下文，默认 GA 版本为 200K |
| Claude 4.6 Sonnet | 1M tokens (Beta) | 兼顾速度与长文本，支持上下文压缩 (Context Compaction) | |
| Claude 4.5 Haiku | 200K tokens | 依然保持极高的性价比和响应速度 | |
| Gemini 3 Pro | 1M - 2M tokens | 视频与超大规模工程代码库处理的标杆 | |
| Gemini 3 Flash | 1M tokens | 在长文本检索（Needle In A Haystack）中表现极稳 | |
| 国产模型 | Kimi K2.5 (Reasoning) | 2M - 10M tokens | 月之暗面依然在长文本领域保持量级领先 |
| DeepSeek-V3 | 128K - 256K tokens | 极致性价比，在长文本内检索的精度极高 | |
| 通义千问 Qwen 3.5 | 1M tokens | 阿里云最新旗舰，对大规模代码库的对齐效果出色 | |
| 豆包 (Doubao-Seed-Code) | 256K 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、向量数组、原始内容或元数据。
// 基础结构（以 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 生成 │
└────────────────┘
知识库由谁来建，什么时候建？
离线构建阶段与大模型训练完全解耦——模型只提供理解和生成能力，知识库由使用方自己负责。开发者或企业在拿到模型 API 之后，根据自身业务需求，随时可以构建或更新知识库。
两个例子：
Cursor（编程场景） 开发者打开一个项目后，Cursor 会在本地实时扫描代码文件，自动完成切片、向量化，并存入本地临时索引。目的是让模型"读懂"你当前的项目上下文——当你问"这个函数在哪里被调用"时，模型能基于你的真实代码回答，而不是凭空猜测。这里知识库的内容就是你自己的项目，每个用户的库都不一样，构建过程对用户无感，自动发生。
企业内部问答（非编程场景） 某保险公司想让员工能用自然语言查询内部理赔规则。IT 团队将数百份 Word 版本的操作手册、产品条款导入系统，完成切片和向量化后存入向量数据库。此后员工提问"轻症赔付比例是多少"，系统先从库里检索相关条款，再交给模型组织成自然语言回答。知识库可以随着文件更新而重新构建，无需重新训练模型。
💡 在线查询阶段，用户问题会被临时向量化用于检索，这个向量不会写入数据库，只是一次性的检索 key。写入操作仅发生在离线的构建阶段。
Top-K 文档是什么？
在相似度检索这一步，系统会把用户问题的向量与知识库中所有文档 Chunk 的向量逐一比较相似度（余弦相似度等），然后按相似度从高到低排序，取出得分最高的前 K 个文档片段，这就是 Top-K 文档。
向量数据库中有 10000 个 Chunk (当询问 "番茄炒蛋怎么做才好吃")
─────────────────────────────────────────────────────
相似度排名 │ Chunk 内容摘要 │ 相似度得分
─────────────────────────────────────────────────────
#1 │ 番茄炒蛋的家常做法 │ 0.94
#2 │ 番茄的挑选与去皮技巧 │ 0.91
#3 │ 鸡蛋嫩滑的火候控制方法 │ 0.87
··· │ ··· │ ···
#10000 │ 红酒醒酒时间与温度指南 │ 0.03
─────────────────────────────────────────────────────
Top-K（K=3）→ 取 #1 #2 #3，拼入 Prompt 交给 LLM
K 值是一个可调参数，通常取 3~10。K 越大，检索到的上下文越丰富，但也会消耗更多 Context Window 空间并引入噪音；K 越小，精准度高但可能遗漏关键信息。以菜谱场景为例，K=3 只取番茄炒蛋最核心的三条内容，K=8 则可能额外纳入"鸡蛋的营养成分"或"番茄的品种介绍"——相关但未必有用。
实际工程中通常还会在 Top-K 后接一个 Reranker（精排模型），对这 K 个候选片段做二次评分重排，进一步提升最终送入 LLM 的文档质量。
在菜谱问答场景下，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 │
└──────────────────┘ └──────────────────┘
Host 负责整个生命周期
三层结构里，Host 不只是"UI 界面"，它还是整个 MCP 运行环境的管理者。用户打开 Cursor 时，Host 会读取配置文件，把需要的 Server 作为子进程在后台拉起来，同时创建对应的 Client 实例与之建立连接——这一切对用户无感。用户关闭编辑器时，Host 也负责断开连接、回收所有 Server 进程。Agent 本身不管这些，它只管"通过 Client 要结果"。
Server 有两种形态：一种是 Host 启动的本地子进程（Stdio 通信），生命周期完全跟着 Host；另一种是远程独立部署的服务（HTTP/SSE 通信），Host 只负责连接，不负责启动和关闭。
如果某个工具因环境原因无法使用——比如系统缺少依赖、API Key 未配置——规范的 Server 会在启动阶段做环境检测，不满足条件的工具直接不注册进列表，Client 拿到的 tools/list 就不会包含它。若工具已暴露但执行时才报错，Server 会返回标准错误，由 Host 或 Agent 决定下一步：重试、换工具或提示用户。
你可以开发自己的server服务，但是需要满足MCP相应的规定，因为MCP是业界普遍采用的通信协议。现在各类场景基本都有对应的server了(比如filesystem，GitHub / GitLab， Puppeteer)，开发者和大厂也在持续的贡献新的server
通信协议（JSON-RPC 格式）：
{
"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 编程助手理解某个技术、规范、工具或最佳实践的正确使用方式，并在必要时直接执行相关工具。它的工作方式是按需加载——Claude 判断当前任务与哪些 Skill 相关，再动态载入对应内容，避免无效占用上下文。
一个 Skill 本质上是一个文件夹，由三个核心部分构成：
- 指令（Instructions）：核心文件
SKILL.md，包含 YAML frontmatter（定义名称、描述及触发条件）和 Markdown 正文（编码标准、最佳实践、API 正确用法及需规避的坑） - 脚本（Scripts）：可直接运行的自动化脚本，让 Claude 不只是「读规则」，还能「跑工具」——比如检测依赖版本、执行格式化、生成模板文件等
- 资源（Resources）：
references/目录下的参考文档、API 手册、示例代码，作为 Claude 的上下文补充知识
说人话就是：当我写 Vue 项目时，Claude 会参考我给的 Vue 规则集（API、写法推荐、最佳实践）来给方案，而不是靠训练时学到的旧知识；遇到需要自动化的任务，它还可以直接调用 Skill 内置的脚本来执行。
Agent Skills 是由 Anthropic 主导推动的开放标准，规范发布在 agentskills.io，这意味着按此标准创建的 Skill 不局限于 Claude，支持该标准的其他 AI 平台和工具同样可以复用。Anthropic 官方在 anthropics/skills 仓库中维护了一批示例和生产级 Skill 实现，涵盖文档创建、数据分析、企业工作流等场景，可直接取用或作为自定义 Skill 的参考。社区开源项目 antfu/skills（由 Vue 核心团队成员 Anthony Fu 发起）则将规则文件打包成 npm 包，方便前端开发者复用现成规范，无需从头搭建。
Skills 支持三种来源：
- Anthropic 官方 Skill：由 Anthropic 维护，在 Claude 中自动触发，无需手动安装（如 Word、Excel、PDF 文档能力）
- 自定义 Skill：由个人或团队编写，用于封装特定业务规范、数据分析流程或个人工作习惯
- 合作伙伴 Skill：来自 Notion、Figma、Atlassian 等第三方，与对应 MCP 连接器配合使用，实现集成工作流
创建一个最简 Skill 只需一个带 frontmatter 的 SKILL.md 文件：
---
name: vue-best-practices
description: 当项目使用 Vue 3 时加载，提供 Composition API、script setup 及响应式 API 的最佳实践
---
# Vue 3 最佳实践
## 组件写法
- 优先使用 `<script setup>` 语法
- 使用 `defineProps` 和 `defineEmits` 替代选项式写法
## 响应式
- 对象/数组用 `reactive()`，基础类型用 `ref()`
- 避免直接解构 reactive 对象，使用 `toRefs()`
frontmatter 中只有两个必填字段：name（唯一标识符）和 description（同时作为 Claude 判断是否激活该 Skill 的依据）。对于需要执行能力的 Skill，可在文件夹中额外附加脚本文件。
以 antfu/skills 为例，安装使用方式如下：
# 安装 vue、vite、vue-best-practices 三个 skill
npx add-skill antfu/skills --skill vue --skill vite --skill vue-best-practices
安装时会交互式询问你要支持哪些 Agent，根据选择生成对应目录：
◆ 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
└
安装后生成的目录结构：
.agents/skills/ ← 通用目录，Cursor / Copilot / Codex / Gemini CLI 等都读这里
├── vue/
│ ├── references/ ← 资源：API 手册、示例代码
│ │ ├── core-new-apis.md
│ │ ├── advanced-patterns.md
│ │ └── script-setup-macros.md
│ ├── scripts/ ← 脚本：可运行的自动化工具
│ │ └── check-version.sh
│ └── SKILL.md ← 指令：规范约束 + 触发条件
└── vite/
├── references/
│ └── core-features.md
└── SKILL.md
.claude/skills/ ← Claude Code 专用目录（部分 Agent 有独立目录）
可以把 Skill 理解为：给 Agent 的工作手册 + 工具箱——既告诉它「在这个项目里该怎么写代码」，也给它可以直接调用的工具完成自动化任务，还会在恰当时机自动激活，而不是始终占用上下文。
2.11 其他词汇
Vibe Coding（氛围编程） 一种以自然语言为主导的编程方式：开发者用日常语言描述想要实现的功能，由 AI 自动生成对应代码，开发者的核心工作从"写代码"转变为"审查代码、纠正方向"。它不要求你逐行手写，而是更像在给 AI 当"产品经理"——你负责提需求和把关，AI 负责实现。名字里的"氛围"，指的是这种模糊但有方向感的协作状态。
Multimodal（多模态） 指 AI 模型能同时理解和处理多种类型信息的能力，包括文字、图片、音频、视频等。传统模型往往只能处理一种类型（如纯文字），而多模态模型可以做到"看图说话"、"听录音总结"等跨类型任务。GPT-4o、Claude 3、Gemini 等主流模型均已支持图文混合输入。
Fine-tuning（微调） 大模型经过海量数据的预训练后，已具备通用能力，但在特定领域（如医疗、法律、客服）可能表现不够精准。微调就是在这个基础上，用该领域的专属数据对模型进行"二次训练"，让它在特定场景下表现得更专业、更符合需求。可以类比为：通用大学毕业生入职后接受的岗位专项培训。
Distillation / Knowledge Distillation（知识蒸馏） 一种模型压缩技术。核心思路是：用一个能力强但体积大的"教师模型"来指导训练一个更小、更轻量的"学生模型"，让小模型尽量学到大模型的推理能力，同时大幅降低计算成本和部署门槛。结果是：小模型的体积可能只有大模型的几十分之一，但在很多任务上仍能达到接近的效果。DeepSeek-R1 就采用了这一技术。
三、项目中的上下文配置文件
这些文件的共同目的只有一个：为 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 在任何时候都会综合多个信息源做判断，优先级依次是：
- 当前对话窗口——最新、最权威的信息
- AGENTS.md / 系统提示词——启动时就注入好的角色定义和规则
- RAG 检索结果——按需从文档库里临时捞出来的相关内容
- 向量数据库里的长期记忆——历史对话的语义摘要
- 模型本身的训练知识——静态的，不会实时更新
主流程
① 用户发出需求 → 输入护栏
用户说了一句话（比如"帮我给登录接口加上 rate limiting"），这句话不会直接进大模型，而是先过输入护栏这道关：
- 检查有没有恶意指令（Prompt Injection）或敏感词
- 校验格式是否合法、Token 长度有没有超限
❌ 如果不合规：直接拦截，返回提示，终止流程，并异步写入审计日志。
✅ 如果合规：继续往下走。
② 读取记忆
输入合规后，系统会去记忆服务（一个独立的后台服务，不是 Agent 自己去取）里读三类记忆：
- 短期记忆：这次会话聊了什么
- 长期记忆：用户的偏好、项目上下文（历史积累的）
- 工作记忆：上一轮工具调用返回了什么结果
这些记忆后面会一起打包进 Prompt。
③ 语义路由——判断这个任务该怎么处理
拿到用户的输入后，一个轻量的语义路由模块（不是主 LLM，用小模型或规则引擎，省成本）会分析这个请求是什么类型的任务，然后分流：
| 任务类型 | 走哪条路 |
|---|---|
| 💬 简单问答/推理 | 直接用最小 Prompt + 思维链（CoT）调模型 |
| 📄 文档/知识查询 | 走上下文组装 → 触发 RAG 检索 |
| 🔍 代码审查 | 先做 AST/lint 静态分析，注入 .skills 规范，再调模型 |
| ⚙️ 复杂/需要操作的任务 | 走上下文组装 → 可能触发 RAG → 进入 ReAct 循环 |
④ 上下文组装——把所有材料拼成一个完整的 Prompt
把以下内容打包在一起，准备喂给大模型：
- 系统提示词（角色定义、行为边界、AGENTS.md 规则）
- 刚才读取的记忆
- 用户偏好 &
.skills规范 - 可用工具的描述清单（Tool Schema，告诉模型"你能用哪些工具、每个工具需要什么参数"）
- 当前环境上下文
⑤ 判断是否需要 RAG 检索
上下文组装完后，判断这个任务需不需要去文档库里查资料：
不需要 → 直接给大模型推理。
需要 RAG：
- 把用户的问题临时转成向量（注意：这个向量不会存到数据库，只是临时用）
- 拿这个向量去 Vector DB 里做相似度检索，找出最相关的 Top-K 段落（Chunk）
- 可选：用 Reranker 精排模型对这些结果重新排序，挑最相关的
- 把检索到的内容合并注入 Prompt，同时标注来源引用
- 然后再给大模型推理
📌 RAG 的文档是怎么进 Vector DB 的？
Vector DB 有两条写入路径：
- 离线索引：外部文档（PDF / Wiki / 代码库等）经"文档加载 → 切分成小 Chunk（带重叠，避免上下文断裂）→ 向量化 → 存入 Vector DB"流水线预处理，与实时请求无关，提前跑好。
- 在线写回：每轮对话结束后（第 ⑪ 步），对话摘要同样会被向量化写入 Vector DB，作为长期记忆。这条路径是实时触发的，下次对话的 RAG 检索就可能命中它。
⑥ LLM 推理（ReAct 循环的入口）——整条链路最核心的节点
大模型拿到完整的 Prompt（包含系统提示、记忆、RAG 结果、用户输入、工具清单），开始推理：
- 理解需求，做思维链推理，制定执行计划
- 输出两种结果之一：
- 直接输出文本（不需要用工具）→ 进入输出护栏
- 输出
tool_call（声明要调用某个工具，带上参数）→ 进入工具权限校验
⑦ 工具权限校验
模型说"我要调用这个工具"之后，不会直接就跑，先过权限检查：
- 这个工具当前用户有没有权限用？
- 传入的参数合不合规？
❌ 无权限 / 参数违规：拒绝执行，把错误信息返回给模型，让它重新想。
✅ 通过：判断这次要不要并行调多个工具，然后去执行。
⑧ MCP 工具执行
通过 MCP Client 把工具调用指令路由到对应的 MCP Server，真正在宿主环境里执行各类操作。以下是主要工具类型：
🗂️ 文件 & 本地环境
- 文件读写：读取源码、配置文件，写入生成内容，支持指定路径和编码
- Shell 命令执行：运行脚本、编译构建、执行测试，获取 stdout/stderr
- Git 操作：查看 diff、提交记录、分支信息，辅助代码审查
🌐 网络 & 第三方 API
- GitHub / GitLab API：创建 PR、查看 Issue、触发 CI/CD 流水线
- 第三方 HTTP 服务：调用业务 API、消息推送（Slack、钉钉）、支付 / 短信等接口
🕷️ 网页数据爬取
当需要从公开网页获取实时信息时（如竞品分析、文档抓取、价格监控），Agent 会调用爬取工具：
- 轻量抓取（HTTP Fetch）：直接发 HTTP 请求拿 HTML，适合静态页面；速度快，无需浏览器环境
- 无头浏览器（Headless Browser）：启动 Puppeteer / Playwright，适合 JS 渲染的 SPA 页面；可模拟点击、滚动、等待异步加载
- 内容解析：拿到原始 HTML 后，用 CSS Selector 或 XPath 提取正文、表格、链接等结构化字段，过滤掉导航栏/广告等噪声
- 反爬处理：必要时设置请求头（User-Agent、Referer）、控制请求频率、处理 Cookie / Session，避免被封禁
- 结果回传：将解析后的结构化文本或 JSON 追加至上下文，供模型进一步分析
⚠️ 爬取工具的输出通常是"原始"内容，模型后续还需要做信息提炼，不会直接把整个页面塞进 Prompt（Token 成本过高）。
🗄️ 数据库查询
数据库查询分两种场景，底层机制完全不同：
1. 关系型数据库（SQL）
适用于结构化数据查询，例如查订单、查用户信息、做报表统计。
- 工具收到指令后，生成 SQL 语句（可由 LLM 辅助生成 Text-to-SQL）
- 通过数据库连接池（pg / mysql2 / prisma 等）执行查询
- 返回结构化的行列数据（JSON 或 CSV 格式）
- 注意事项：
- 写操作（INSERT / UPDATE / DELETE）需要严格权限控制，通常设为只读账户
- 复杂查询应加超时限制，防止慢查询阻塞
- 返回结果过大时需截断，只取前 N 行喂给模型
| 典型数据库 | 适用场景 |
|---|---|
| PostgreSQL / MySQL | 业务数据、用量统计、日志查询 |
| SQLite | 本地轻量存储、开发调试 |
| ClickHouse | 大规模分析型查询、时序数据 |
2. 向量数据库（Vector DB / RAG 检索）
适用于语义相似度查询，例如"找出和这段描述最相关的文档片段"，这就是第 ⑤ 步 RAG 流程里用到的那个数据库。
- 查询时先把问题文本转成向量（Embedding）
- 用 ANN（近似最近邻）算法在向量库中检索语义最相近的 Top-K 条目
- 返回的不是精确匹配的行，而是"语义上最接近"的文本块
- 可选接 Reranker 进一步精排，提升相关性
| 典型实现 | 特点 |
|---|---|
| Pinecone | 全托管，开箱即用 |
| Weaviate | 支持混合检索（关键词 + 向量） |
| Qdrant | 高性能，支持过滤条件 |
| pgvector | 在 PostgreSQL 上扩展，无需额外服务 |
| Chroma | 轻量，适合本地开发 |
📌 两种数据库的核心区别：关系型数据库回答"精确是什么"，向量数据库回答"语义上最像什么"。实际项目中二者经常配合使用——先用向量库找出相关文档，再用 SQL 查询文档对应的结构化元数据。
多个工具可以并行分发，异步等待全部结果返回。
⑨ 结果回传——ReAct 的"观察"步骤
工具执行完了，把结果（stdout 输出、文件内容、API 响应、报错信息等）收集起来：
- 有错误：触发错误处理（重试 / 降级 / 换一个工具），然后继续
- 正常：把工具结果追加到 Prompt 的上下文里，同时触发工作记忆更新
然后判断：
- ✅ 任务完成了：进入输出护栏，准备返回结果
- ❌ 还没完成：把新上下文重新喂给大模型，继续推理（回到第 ⑥ 步，形成
tool_call → 执行 → 观察 → 回传 → 继续推理的闭环） - ⚠️ 循环次数超上限：强制终止，返回已完成的部分
⚠️ 循环次数超上限（Max Steps 熔断）：这是框架层的硬性保护机制，防止以下情况导致无限运行：工具死循环调用、持续报错重试、模型推理自我矛盾、输出护栏反复拦截、任务缺乏明确终止条件等。触发后强制中断，返回当前已完成的部分内容，并告知用户任务未完整执行。
⑩ 输出护栏
模型最终的输出在返回给用户前，还要过一道检测：
- 合规性校验（有无违规内容）
- PII 过滤（有没有暴露隐私信息）
- Hallucination 检测（有没有明显的幻觉）
- 有害内容过滤
❌ 检测不通过：触发修复器（Corrector），尝试修正 / 重写 / 截断内容，修复后重新检测。如果修复次数超限，就降级返回一个兜底响应，引导用户重新描述需求。
✅ 检测通过：进入记忆写回。
⑪ 记忆写回
本次对话结束后，把有价值的信息异步写回记忆服务：
- 对话摘要 → 长期记忆
- 工具执行结果 → 工作记忆
- 用户行为信号 → 偏好更新
这样下次对话时，Agent 就能"记得"这次发生了什么。
⑫ 审计日志（audit log）
整条链路全程有审计层在旁路异步记录（完全不阻塞主流程）：
- 完整的调用链路和输入输出快照
- Token 用量、延迟、安全事件
- 用途：合规审查、故障排查、用量统计、安全溯源
审计日志数据库主要记录的就是每次执行过程，存储过程由审计层监听并记录，而非agent发起。
一图胜千言：
五、主流工具横向对比
这些工具都内置了 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 在人类重复性工作中的参与度也会越来越高。带来的是效率还是新的复杂性？可能两者都有。但这大概率是接下来的方向。
