关键词说明

起点：大模型语言

大语言模型（LLM, Large Language Model） 是一种基于深度学习的人工智能系统，核心能力是通过学习海量文本数据，理解并生成人类语言。

以下是通俗易懂的拆解：

1. 本质：高级"文字接龙"玩家

想象一个读过万亿级文字（书籍、网页、代码、对话）的"超级学霸"。

当你输入"今天天气"，它会基于学到的规律，预测下一个最可能出现的词：

"很好"（概率 40%）
"晴朗"（概率 35%）
"糟糕"（概率 10%）

然后不断重复这个过程，生成完整的句子、段落甚至长文章。

技术术语：这叫 "自回归生成"（Auto-regressive Generation）。

2. 关键能力（与传统软件的区别）

能力	传统软件（如SonarQube）	大语言模型（LLM）
理解方式	基于固定规则（正则、配置）	基于概率和模式（模糊理解）
处理输入	必须严格格式化（API参数、JSON）	可以理解自然语言（"帮我查昨天的高危漏洞"）
输出结果	精确、确定性（0或1）	概率性、创造性（可能给出意外但合理的答案）
适应性	改规则需重部署	通过提示词（Prompt）即时调整行为

3. 典型应用场景

智能客服/问答：直接回答技术问题（如解释SonarQube错误）
代码辅助：GitHub Copilot、通义灵码（自动生成/补全代码）
文本分析：从非结构化文本（如邮件、日志）中提取关键信息
内容生成：写文档、生成测试用例、翻译技术文档

4. 重要局限性（使用须知）

"幻觉"（Hallucination）：可能自信地编造不存在的信息（比如虚构一个不存在的SonarQube参数）
知识截止：模型训练数据有截止日期（如GPT-4知识截止到2024年初），不知道最新版本特性
无状态：每次对话独立，不自动保存上下文（除非程序特别处理）
计算成本：相比查数据库，调用LLM API成本高、延迟大（几百毫秒到几秒）

创造价值：从对话到记忆

1. Prompt（提示词）= 你现在说的话

就是当前的指令或问题。

例子："把这段话翻译成英文"、"我叫张三"
特点：一次性的，说完就完了

2. Context（上下文）= 聊天记录

就是本次对话的历史记录。

例子：你刚才说"我叫张三"，助手记住了；然后你问"我叫什么"，助手翻看**聊天记录（Context）**回答"张三"
特点：关窗口就消失，下次打开新对话就清零了

3. Memory（记忆）= 备忘录/小本本

就是跨会话保存的长期记忆（通常需要存到数据库）。

例子：你告诉助手"以后请用正式语气回答我"，助手把这个偏好写进数据库（Memory），下次你开新对话，它还记得用正式语气
特点：永久保存，除非主动删除

一句话总结关系

Prompt 是当前问题，Context 是短期记忆（本次聊天），Memory 是长期记忆（存硬盘）。

类比流程图：

你: "我叫张三"（Prompt）→ 助手看 Context（空）→ 回答"你好张三"
你: "我叫什么？"（Prompt）→ 助手看 Context（之前说过叫张三）→ 回答"张三"
[关窗口]
[第二天重开]
你: "我叫什么？"（Prompt）→ 助手看 Context（空的），查 Memory（空的）→ 回答"我不知道"

添加工具：智能体的诞生

Agent（智能体）

用户向智能体下达复杂任务
智能体判断：“我需要LLM大脑，还是外部工具？“
智能体执行工具和/或调用LLM
智能体将最终整合的结果返回给用户

Agent 的核心特点

自主决策：根据任务自动选择使用工具还是调用LLM
工具集成：可以调用多个外部工具（API、数据库、搜索引擎等）
迭代执行：支持多轮交互，逐步完成复杂任务
结果整合：将多个信息源的结果综合处理后返回给用户

例子：

用户: "帮我查一下明天北京的天气，然后告诉我穿什么衣服"
智能体流程:
1. 识别需求：需要天气工具 + LLM建议
2. 调用天气API → 获得"明天北京15°C，有雨"
3. 调用LLM → 基于天气数据生成穿衣建议
4. 返回结果："明天北京有雨，建议穿长袖+外套"

一句话结论：Agent 是身体，LLM 是大脑——没有大脑的身体是植物人，没有身体的大脑只能干瞪眼。

你不能不要 LLM，就像你不能让一辆车"包含引擎的一切功能"但却拆掉引擎。

1. 分层架构：Agent 是"壳"，LLM 是"核"

从软件架构看，它们的关系是组合而非替代：

┌─────────────────────────────────────┐
│           Agent（智能体）            │  ← 你写的代码：工具调用、记忆管理、流程控制
│  ┌─────────────────────────────┐    │
│  │      LLM（大语言模型）       │    │  ← 外部API：思考、推理、决策
│  │  · 理解你的指令              │    │
│  │  · 规划执行步骤              │    │
│  │  · 生成代码/参数             │    │
│  └─────────────────────────────┘    │
│  ┌─────────────────────────────┐    │
│  │   Tools（工具集）            │    │  ← Sonar API、数据库、邮件服务
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

关键区别：

Agent 负责"动手"：调用 API、操作数据库、记录日志
LLM 负责"动脑"：理解需求、规划步骤、生成参数

如果没有 LLM，你的 Agent 就变成了传统脚本：

// 没有 LLM 的 "Agent"（其实就是个脚本）
function 传统脚本() {
    // 没有思考能力，只能写死逻辑
    const issues = 调用SonarAPI();
    if (issues.length > 0) {
        插入数据库(issues);
    }
    // 遇到意外情况（API返回新字段、数据格式变了）直接崩溃
}

有了 LLM 的 Agent：

// 真正的 Agent
async function 智能Agent(用户需求) {
    // LLM 理解模糊需求
    const 执行计划 = await LLM.规划(`
        用户说："${用户需求}"
        请规划执行步骤，考虑异常处理
    `);

    // LLM 动态生成代码/参数
    for (const 步骤 of 执行计划) {
        if (步骤.类型 === '调用Sonar') {
            const 参数 = await LLM.生成参数(`
                根据需求提取查询参数：${用户需求}
            `);
            const 结果 = await SonarAPI.查询(参数);

            // LLM 处理异常（比如新字段）
            if (结果.有未知字段) {
                await LLM.自适应处理(结果);
            }
        }
    }
}

2. 为什么 "Agent 包含 LLM 功能" 是错觉？

你觉得"Agent 包含 LLM 的一切"，可能是因为：

你通过 Agent 调用 LLM
Agent 包装了 LLM 的 API
最终功能看起来都是"智能回答"

但剥离 LLM 后，Agent 只是空壳：

功能	有 LLM 的 Agent	无 LLM 的 "Agent"（普通程序）
理解模糊指令	✅ "同步最近有问题的代码"	❌ 只能识别 `sync --branch=master --status=OPEN` 这种精确命令
处理意外情况	✅ API 返回新字段，LLM 自动适应	❌ 直接崩溃或数据丢失
多步骤规划	✅ 自动拆解：查Sonar→分析→写库→发邮件	❌ 只能按预设死流程执行
生成动态内容	✅ 根据数据自动生成分析报告	❌ 只能填充固定模板

3. 总结：正确的使用姿势

LLM 是大脑 → 负责思考、理解、决策
Agent 是身体 → 负责执行、记忆、协调工具

关系：Agent 调用 LLM，而非替代 LLM

RAG（检索增强生成）

用一个生活例子理解

想象你是一个参加考试的学生：

📚 普通 AI (没有RAG)
= 只能用脑子里记住的知识答题
= 知识有截止日期，可能答错或瞎编

📖 RAG 的 AI  
= 考试时允许带小抄/参考资料
= 先查资料，再结合资料回答
= 答案更准确、更有依据

RAG 是什么？

Retrieval（检索）Augmented（增强）Generation（生成）

简单说就是：

先去查相关资料  →  再根据资料回答问题

"有据可查"的 AI 回答方式

工作流程

你提问："我们公司的年假政策是什么？"
         ↓
   🔍 第一步：检索
   AI 去公司文档库搜索
   找到《员工手册第3章：年假规定》
         ↓
   📋 第二步：获取相关内容
   "员工入职满1年可享有10天年假..."
         ↓
   🤖 第三步：生成回答
   AI 结合找到的内容，
   用自然语言组织成完整回答
         ↓
   💬 最终回答：
   "根据公司规定，您入职满1年后
    可以享有10天带薪年假..."

对比理解

	普通 AI	RAG
知识来源	训练时学的	实时查询文档
知识时效	有截止日期	实时最新
会不会瞎编	可能会	较少，有依据
能否用私有数据	❌	✅
例子	凭记忆答题	开卷考试

真实使用场景

🏢 企业内部知识库
   员工问：项目A的技术方案是什么？
   AI 查：内部文档 → 准确回答

📜 法律咨询
   用户问：合同第5条怎么理解？
   AI 查：具体合同内容 → 精准解释

🏥 医疗问答
   医生问：患者用药有无冲突？
   AI 查：最新药典资料 → 给出建议

💻 代码助手
   开发问：我们项目怎么调用这个接口？
   AI 查：项目文档/代码 → 给出示例

核心价值

解决了 AI 的三大痛点：

1. 📅 知识过时
   → RAG 可以查最新文档

2. 🤥 一本正经的胡说八道（幻觉）
   → RAG 基于真实资料回答

3. 🔒 不了解你的私有数据
   → RAG 可以接入你的私有知识库

一句话总结

RAG = 给 AI 配了一个"实时搜索引擎"

让 AI 回答问题之前，
先去你指定的资料库查一查，
再给你一个有据可查的回答

就像让 AI 从"死记硬背"
升级为"开卷考试" 📖✨

Function Calling

一句话解释

给 AI 配了一套"工具"
AI 自己决定什么时候用哪个工具

生活例子

你有一个超级助理（AI）

你给他配了几个工具：
🔧 计算器    - 算数学题
🌤️ 天气查询  - 查天气
📅 日历      - 查日程
📧 发邮件    - 发送邮件

你说："帮我看看明天天气，
       如果下雨就帮我把户外会议改到室内"

助理自动：
1. 调用天气工具 → 查明天天气
2. 发现明天下雨
3. 调用日历工具 → 修改会议地点
4. 回复你结果

工作流程

用户提问
   ↓
AI 分析：我需要用什么工具？
   ↓
AI 调用对应工具（函数）
   ↓
获取工具返回结果
   ↓
AI 组织语言回答用户

代码直观感受

// 你提前告诉 AI 有哪些工具可以用
tools: [
  {
    "name": "get_weather",
    "description": "查询天气",
    "parameters": {
      "city": "城市名"
    }
  },
  {
    "name": "send_email",
    "description": "发送邮件",
    "parameters": {
      "to": "收件人",
      "content": "内容"
    }
  }
]

// AI 自己决定调用哪个
// AI → 调用 get_weather(city="北京")
// AI → 调用 send_email(to="xx", content="xx")

MCP（Model Context Protocol）

一句话解释

Function Calling 是给一个 AI 配工具
MCP 是制定了一套标准
让所有 AI 都能用所有工具

生活例子

没有 MCP 之前：
😫 每个电器充电口都不一样
   苹果用苹果线
   安卓用安卓线
   相机用相机线
   = 每个 AI 工具都要单独适配

有了 MCP 之后：
😄 统一用 Type-C 充电口！
   一根线走天下
   = 工具写一次，所有 AI 都能用

对比理解

Function Calling        MCP
─────────────────      ──────────────────
单个 AI 的工具调用      跨 AI 的工具标准协议
─────────────────      ──────────────────
厂商各自定义格式        统一标准格式
─────────────────      ──────────────────
工具要单独适配          工具写一次到处用
─────────────────      ──────────────────
范围小                  范围更大

MCP 架构

        MCP 标准协议
            ↕
  ┌─────────────────────┐
  │    MCP Server        │  ← 提供工具的地方
  │  (工具/数据提供方)    │
  │  - 文件系统          │
  │  - 数据库            │
  │  - 第三方API         │
  └─────────────────────┘
            ↕
        MCP 标准协议
            ↕
  ┌─────────────────────┐
  │    MCP Client        │  ← 使用工具的地方
  │    (AI 应用)         │
  │  - Claude            │
  │  - GPT               │
  │  - 其他AI            │
  └─────────────────────┘

两者关系

Function Calling 是 MCP 的基础能力

Function Calling  →  AI 能调用工具
MCP              →  规范了怎么调用工具的标准

就像：
Function Calling = 汽车能加油这个能力
MCP             = 统一了加油口的标准规格

总结对比

	Function Calling	MCP
是什么	AI调用工具的能力	工具调用的统一标准
解决什么	AI能用外部工具	工具跨AI复用
范围	单个AI应用	整个AI生态
类比	会用工具	工具接口标准化
谁提出	OpenAI	Anthropic(Claude)

一句话记忆

Function Calling：
"AI 学会了使用工具" 🔧

MCP：
"所有 AI 和工具说同一种语言" 🌐

构建工作流：从代码到技能

LangChain、Workflow、Skill、纯Agent 简单说明

先用一个比喻整体理解

把 AI 完成任务想象成"做一道复杂的菜"

Skill      = 单个厨艺技能（切菜、炒菜、摆盘）
Workflow   = 按菜谱一步步做（固定流程）
纯Agent    = 大厨自由发挥（自己决定怎么做）
LangChain  = 厨房里所有工具和设备的集合

Skill（技能）

是什么

一个独立的、可复用的单一能力

就是一个具体会干某件事的模块

例子

🔍 搜索技能    - 会搜索网络信息
📝 总结技能    - 会总结文章内容  
🌤️ 天气技能    - 会查天气
💰 计算技能    - 会做数学计算
📧 发邮件技能  - 会发送邮件

特点

✅ 功能单一
✅ 可以被复用
✅ 像积木一样可以随意组合
❌ 单独使用能力有限

我们刚才的对话已经磨合出了完整的工作流程和输出标准。请现在将这个过程整理成一个标准的Agent Skill,要求如下: 1.创建完整的Skill文件夹结构 2.SKILL.md写清楚:Skill职责、触发场景、执行步骤、输出标准 3.references放入我们确认过的所有格式要求和内容标准 4.可自动化的步骤写入scripts 5.assets放入需要复用的模板文件 6.在 SKILL.md 中添加版本信息块输出一个我可以直接安装使用的Skill文件夹

Workflow（工作流）

是什么

把多个 Skill 按固定顺序串起来
流程是提前定好的，不会变

例子

"每天早报生成" Workflow：

第一步 → 搜索今日新闻
   ↓
第二步 → 筛选重要内容
   ↓
第三步 → AI 总结成摘要
   ↓
第四步 → 发送到邮件/微信

流程固定，每次都这样走

特点

✅ 流程可控、稳定
✅ 结果可预期
✅ 适合固定业务流程
❌ 不灵活，遇到意外不会变通
❌ 流程要人工提前设计好

纯 Agent

是什么

给 AI 一个目标
AI 自己思考、自己决定怎么做
自己选工具、自己规划步骤

例子

你说："帮我调研一下竞争对手，
       出一份分析报告"

Agent 自己思考：
🤔 我需要做什么？
   ↓
1. 先搜索竞争对手信息      ← 自己决定
   ↓
2. 发现需要看他们官网      ← 自己决定
   ↓
3. 抓取官网内容分析        ← 自己决定
   ↓
4. 对比数据整理成表格      ← 自己决定
   ↓
5. 生成分析报告            ← 自己决定

全程 AI 自主规划，不需要人指定步骤

特点

✅ 非常灵活
✅ 能处理复杂、未知的任务
❌ 结果不可控
❌ 可能走弯路，消耗多
❌ 有时会"乱来"

LangChain

是什么

不是一种模式
而是一个开发框架/工具库

帮你快速构建上面三种东西的工具集合

包含什么

LangChain 工具箱里有：

🔗 Chain       - 帮你串联多个步骤（Workflow）
🤖 Agent       - 帮你构建自主 Agent
📚 RAG 工具    - 帮你做知识库检索
🔧 Tools       - 各种预置 Skill 工具
💾 Memory      - 帮 AI 记住上下文
📋 Prompt 管理 - 管理提示词模板

类比

LangChain 就像：

盖房子时的"建筑工具包"
砖头、水泥、脚手架都帮你准备好了
你专注设计房子就行

而不是你自己去造砖头

四者对比总结

复杂度 & 灵活度

Skill          最简单，单一能力
  ↓
Workflow       固定流程，多个Skill组合
  ↓
纯Agent        自主决策，高度灵活
  ↓
LangChain      构建以上三种的框架工具

	Skill	Workflow	纯Agent	LangChain
是什么	单一技能	固定流程	自主决策	开发框架
灵活性	⭐	⭐⭐	⭐⭐⭐⭐⭐	-
可控性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	-
适合场景	单一功能	固定业务	复杂未知任务	快速开发
类比	单个技能	菜谱流程	大厨自由发挥	厨房设备

实际怎么选？

任务简单固定          →  用 Skill
──────────────────────────────────
流程清晰可预期        →  用 Workflow
──────────────────────────────────
任务复杂、不确定      →  用 纯Agent
──────────────────────────────────
想快速搭建以上任何一种 →  用 LangChain

一句话记忆

Skill      → AI 的一个具体技能 🔧
Workflow   → AI 按剧本演出 📋
纯Agent    → AI 自由发挥 🤖
LangChain  → 搭建AI应用的工具箱 🧰

全局视角：本质与未来

“智能体，是由所有‘不需要智能’的部分构成的”