这是《AI 入门指南》拆分系列第 4 篇。前一篇我们只讲了 Agent 的最小系统骨架；这一篇开始补最关键的基础设施：方法怎么沉淀、工具怎么连接、知识怎么检索、知识库怎么维护。

如果说上一篇回答的是“Agent 为什么是一个系统”，那么这一篇要回答的就是：这个系统到底靠什么站稳。

很多人一走到这里，就会被一串术语绕晕：Skill、MCP、RAG、GraphRAG、HyDE、LLM Wiki……看起来每个都像一个新世界入口。

但如果把它们放回一个更顺手的坐标系里，你会发现它们其实是在回答同一类问题：

• 方法怎么复用
• 外部能力怎么连接
• 知识怎么按需找回来
• 知识库怎么从“能查”走向“能维护”

Skill：把偶然发挥变成稳定方法

如果你真的做过几次重复型任务，很快就会意识到：光靠模型临场发挥，其实并不稳。Skill 之所以重要，就是因为它在解决这个问题。

Skill 可以理解为 Agent 的“能力包”或“套路模板”。它不是模型本身，而是一套可复用的任务方法：什么时候触发、目标是什么、按什么步骤做、要读哪些信息、输出成什么格式、有哪些常见坑。

例如：

• 代码审查的 Skill
• 整理会议纪要的 Skill
• 仓库 Wiki 生成的 Skill
• 客服工单分流的 Skill
• 客户邮件分类与回复草稿的 Skill
• 插件迁移的 Skill

Skill 的本质，是把“偶然发挥得不错”变成“同类任务可以稳定完成”。

Skill 解决的是：怎么把模型能力沉淀成可重复使用的工作方法。

一个 Skill 如果往工程里落，最常见的骨架通常包括：

 1name: code-review-skill
 2trigger:
 3  - 用户请求 review
 4  - 检测到 git diff 存在
 5input:
 6  - changed_files
 7  - diff
 8  - relevant_context
 9output:
10  - findings
11  - risk_level
12  - followup_actions
13steps:
14  - read diff
15  - inspect affected modules
16  - identify correctness and regression risks
17  - summarize findings by severity
18config:
19  timeout: 300
20  max_issues: 50
21  allowed_tools:
22    - read_file
23    - ast_analysis
24    - security_scan
25    - llm_generate

关键不是 yaml 长什么样，而是：你已经开始把“这次运气好做对了”，变成“下次也能稳定做对”。

MCP：把 Agent 接上外部世界

如果 Skill 解决的是“怎么做”，那 MCP 更像是在解决“能连什么”。

第一次理解 MCP 时，最顺手的类比通常是：它有点像 AI 世界里的统一插座。它的目标不是替你完成任务，而是让 AI 更统一地连接外部工具和数据源，而不是每个客户端、每个平台都重新造一套接法。

通过这类标准化连接，Agent 可以更方便地接入：

• 文件系统
• 浏览器
• GitHub
• 数据库
• 文档库
• 企业内部服务

所以 MCP 的价值，不是“模型突然变聪明了”，而是：

• 工具接入成本下降
• 生态复用性提高
• 外部能力开始变成可组合的系统部件

简单说：

• Skill 偏方法层：决定“怎么做”
• MCP 偏连接层：决定“能接什么”

一个更完整一点的 MCP 配置，通常会长这样：

 1{
 2  "mcpServers": {
 3    "filesystem": {
 4      "command": "npx",
 5      "args": ["@modelcontextprotocol/server-filesystem", "/home/user/documents"],
 6      "env": {
 7        "ALLOWED_PATHS": "/home/user/documents:/home/user/projects"
 8      }
 9    },
10    "github": {
11      "command": "npx",
12      "args": ["@modelcontextprotocol/server-github"],
13      "env": {
14        "GITHUB_TOKEN": "${env:GITHUB_TOKEN}"
15      }
16    },
17    "postgres": {
18      "command": "npx",
19      "args": ["@modelcontextprotocol/server-postgres"],
20      "env": {
21        "POSTGRES_URL": "postgresql://user:pass@localhost:5432/db"
22      }
23    }
24  }
25}

关键不是配置格式，而是你终于把“模型能力”和“外部世界能力”拆开思考了。

RAG：让模型在需要时拿到正确知识

Agent 要想在真实环境里可用，光有推理能力远远不够，它还必须拿到正确的知识。这也是为什么很多人做着做着，最终都会走到 RAG。

RAG，全称是检索增强生成（Retrieval-Augmented Generation）。它的逻辑其实很简单：

1. 先从知识库中检索相关资料
2. 再把检索到的内容送进模型上下文
3. 最后基于这些真实资料做回答或执行

这就像给模型加了一个外挂的知识层。模型不需要把所有内容都“背下来”，只需要在需要的时候能找到对的材料。

RAG 的实战会涉及很多工程问题：

• 文档怎么切片
• Embedding 怎么生成
• 向量库怎么选
• 检索结果怎么排序和去重
• 权限怎么做隔离
• 知识更新怎么同步

但从理解层面，你只需要抓住一句话：

RAG 解决的是“模型怎么知道该知道的东西”。

RAG 系统架构

一个完整的 RAG 系统，大致会有这样一条链路：

向量数据库选型指南

如果你开始真正选型，至少要回答这几个问题：你是更需要快速原型，还是生产级过滤能力；是更希望复用现有数据库，还是愿意单独维护向量基础设施；是更偏个人知识库，还是企业级大规模检索。

下面这张表可以先帮你建立直觉：

进一步压缩成选型直觉，大概就是：

• 小规模、低运维：Chroma、pgvector
• 生产级、过滤强：Qdrant
• 关系复杂或多模态：Weaviate
• 超大规模：Milvus
• 不想运维：Pinecone

如果你更喜欢把它写成一个工程判断函数，大概会接近这样：

 1def select_vector_db(requirements):
 2    if requirements["scale"] < 1_000_000 and requirements["ops"] == "minimal":
 3        if requirements["existing_db"] == "postgresql":
 4            return "pgvector"
 5        return "chroma"
 6
 7    if requirements["scale"] < 10_000_000 and requirements["query_complexity"] == "high":
 8        if requirements["multimodal"]:
 9            return "weaviate"
10        return "qdrant"
11
12    if requirements["scale"] > 10_000_000:
13        return "milvus"
14
15    if requirements["no_ops"]:
16        return "pinecone"

RAG 性能优化实战

RAG 系统真正跑起来后，性能优化会成为核心议题。最常见的优化手段包括：

另一个经常被低估的问题是切片策略。切得太大，相关性差；切得太碎，语义又断掉。很多 RAG 调优最后并不是在改模型，而是在改：

• 切片大小
• 切片重叠
• 检索数量
• 重排序位置
• 权限过滤顺序

如果再压缩一点，RAG 性能优化最常见的几件事就是：

• 切片粒度不要过大，也不要碎到失去语义
• 检索后通常还需要重排序
• 权限隔离必须与检索链路一起设计
• 更新同步不能靠人工补记
• 不要迷信“向量库一接就有记忆”

GraphRAG 与 HyDE：RAG 的两个进阶方向

当标准 RAG 开始落地后，大家很快又会发现新的问题：有些问题不是“找一段最像的文字”就能解决的。

比如：

• 某个人和某个组织之间到底是什么关系
• 某次事件的前因后果跨了哪些文档
• 某个概念在多个资料源里是怎么互相引用的

这时候，GraphRAG 就变得有吸引力了。你可以把它理解成：在普通相似度检索之外，再把实体、关系和结构也纳入检索过程。

而 HyDE（Hypothetical Document Embeddings）则是另一种优化思路：先让模型写出一个“假设性答案”，再拿这个答案去做检索，帮助召回更相关的资料。

如果把三者关系粗略压缩一下：

• RAG：先查再答
• GraphRAG：强调关系和结构
• HyDE：强调如何让查询更像目标答案

LLM Wiki：让知识库从“可检索”走向“可维护”

如果继续顺着这条线往前走，你还会遇到另一个很有意思的思路：LLM Wiki。

传统 RAG 的感觉是：你上传一堆资料，提问时系统去找相关片段，然后模型基于片段组织答案。这当然有用，但很多知识每次都要重新发现、重新拼装、重新综合。

而 LLM Wiki 的思路，是在原始资料和最终回答之间增加一个持续演化的中间层。这个中间层不是向量库，而是一套由 LLM 维护的 Markdown Wiki。

它大致分成三层：

1. Raw Sources：原始资料层，只读，是事实源头
2. Wiki：LLM 持续维护的中间知识层，包含摘要页、主题页、实体页、比较页
3. Schema：规则层，告诉 LLM 如何维护目录结构、命名规范、索引和更新流程

如果说 RAG 更像“临时查资料”，那 LLM Wiki 更像“把知识编译成一个持续生长的 AI-native 笔记系统”。

它和传统“把文档塞进聊天框”最大的差别，在于：知识不再只在提问时临时被拼起来，而是会被持续整理、持续链接、持续维护。

如果把它的运行方式再拆开，可以把 LLM Wiki 理解成三类动作：

1. ingest：新资料进来时，不只是存档，而是更新摘要、主题页、实体页和索引。
2. query：回答问题时，优先读已经维护好的 Wiki，而不是每次都从零扫原始资料。
3. lint：定期检查冲突、过期内容、孤儿页、断裂链接和知识空洞。

这也是为什么 LLM Wiki 更像“维护一个知识工件”，而不是“临时调用一次检索能力”。

这一篇真正想留下什么

如果把这一篇压成一句话，那就是：

Agent 真正开始有用，不只是因为它会行动，而是因为它终于有了方法层、连接层、检索层和知识维护层。

也正因为如此，接下来的问题就不再是“这些能力能不能搭起来”，而是“搭起来之后，怎么让它稳定、可控、可测、可维护”。

下一篇，我们就专门讲这一层：Harness Engineering、Eval、Guardrails、Versioning、Observability 和 LLMOps。