夜雨聆风概念全景图
这些概念不是孤立的，它们构成了一条从"人指挥模型"到"模型自主行动"的进化链：
Prompt / Token 基础层：人与模型交互的最小单元 │ ▼Context 承载层：对话的"记忆空间" │ ├──────────────────────────────────┐ ▼ ▼RAG Skill / Tool 能力层：让模型突破自身限制(知识增强) (行动增强) │ │ └────────────┬─────────────────────┘ ▼ MCP 连接层：标准化的"万能插头" │ ▼ Agent 执行层：自主规划与决策 │ ▼ Agentic Workflow 编排层：多 Agent 协同工作 │ ▼ Feedback 进化层：从错误中学习，持续改进一、Prompt（提示词）
是什么
Prompt 是你发给模型的指令——一条消息、一个问题、一段描述。它是人与模型交互的唯一入口。
由来与发展
起源（2020 年以前）：早期的语言模型只是做"完形填空"，prompt 就是那个需要被补全的句子前缀。GPT-2 时代，人们发现改变前缀的措辞会戏剧性地影响输出质量。
关键转折（2020 - GPT-3）：OpenAI 发布 GPT-3 论文，提出了 In-Context Learning（上下文学习），发现只要在 prompt 里放几个例子，模型就能学会新任务而无需微调。这就是 Few-Shot Prompting。
进化到推理（2022 - CoT）：Google 的论文 "Chain-of-Thought Prompting" 发现，在 prompt 里加上"让我们一步一步思考"，模型的数学推理能力就大幅提升。prompt 从"下指令"进化到了"教方法"。
结构化时代（2023 至今）：prompt 不再是随便写几句话，而是一门工程学科——Prompt Engineering。出现了 System Prompt（系统级约束）、结构化 Prompt 模板、Dynamic Prompt（根据上下文动态拼接）等。
解决了什么问题
让普通人用自然语言就能操控复杂的 AI 模型，无需编程。一个好的 prompt 可以让同一个模型的表现有天壤之别。
不足
- 脆弱性
：改一个词可能完全改变输出质量 - 不可迁移
：为 GPT-4 优化的 prompt 在 Claude 上效果可能不好 - 长度限制
：复杂任务的 prompt 可能长达数千字，挤占模型的"注意力" - 安全隐患
：Prompt Injection（注入攻击）可以绕过模型的安全限制
二、Token（词元）
是什么
模型读取文本的最小单位。不是"字"，也不是"词"，而是介于二者之间的片段。
"我喜欢 AI" → ["我", "喜欢", "AI"] ← 3 个 token"hello world" → ["hello", " world"] ← 2 个 token由来与发展
本质原因——模型不理解文字：模型内部全是矩阵运算，不能直接处理文字。必须先把文字转成数字（Embedding），再输入模型。Tokenization 就是这个"转数字"的第一步。
分词算法演进：
- Word-Level（词级）
: 每个词一个 token。词表太大（数百万），生僻词无法处理。 - Character-Level（字符级）
: 每个字母一个 token。序列太长，效率低。 - Subword-Level（子词级，当前主流）
: BPE（字节对编码）和 SentencePiece 算法。高频词保持完整，低频词拆成子词。平衡了词表大小和序列长度。
Token 经济学：从 GPT-3.5 开始，API 按 token 计费。上下文窗口用 token 衡量。Token 成了衡量模型"脑容量"和"使用成本"的核心指标。
中文：约 1.5 个汉字 = 1 token 英文：约 0.75 个词 = 1 token 代码：约 1 个字符 = 1 token（取决于语言）
解决了什么问题
让连续的文本变成了可被计算机计算的离散序列，打通了自然语言和数学运算之间的桥梁。
不足
- 浪费严重
：同一个意思，不同语言消耗的 token 数差异巨大（中文比英文省 token） - 数字处理弱
："2024" 可能被拆成 "20" + "24"，模型很难理解数值大小关系 - 多语言偏见
：分词器对英语最友好，对其他语言可能产生奇怪的拆分 - 成本不透明
：用户看不到 token 拆分过程，不知道为什么"贵"
三、Context（上下文）
是什么
模型在处理当前消息时能"看到"的所有历史信息。包括系统提示词、对话历史、附加文档等。
由来与发展
没有上下文的时代（2022 以前）：每次对话都是独立的，模型不记得你上次说了什么。每次都要重新交代一遍背景。
上下文窗口的军备竞赛：
GPT-3 (2020) → 2K tokens ≈ 一篇短文GPT-3.5 (2022) → 4K tokens ≈ 一篇小论文GPT-4 (2023) → 8K-32K ≈ 一本书的章节Claude 2 (2023) → 100K ≈ 一本书Gemini 1.5 (2024) → 1M tokens ≈ 《三体》第一部Claude 4 (2025) → 200K ≈ 长篇小说关键洞察：上下文窗口不再是限制因素，但更大的窗口不等于更好的理解。"大海捞针"测试（在长文本中藏一句话，问模型相关内容）发现，窗口越大，模型越容易忽略中间的信息（Lost in the Middle 问题）。
上下文管理：随着 Agent 发展，出现了 Context Engineering——如何压缩、摘要、修剪对话历史，让模型始终有最相关的上下文，而不是简单地塞满窗口。
解决了什么问题
让模型拥有了"记忆"。一次对话中可以持续引用之前的讨论，不需要用户反复重复。
不足
- Lost in the Middle
：模型对文本开头和结尾关注度高，中间部分容易被忽略 - 注意力稀释
：上下文越长，模型对每条信息的"注意力"越薄 - 成本递增
：每次请求都要处理全部上下文，长对话的 API 费用会越来越高 - 信息泄露风险
：多轮对话的上下文可能包含敏感信息，一旦泄露整个对话都暴露
四、RAG（检索增强生成）
是什么
让模型在回答问题前，先去外部知识库检索相关资料，基于检索到的资料来生成回答。相当于给模型"开卷考试"的能力。
传统 LLM： 问题 → 模型凭记忆回答（闭卷）RAG： 问题 → 检索相关文档 → 文档 + 问题 → 模型参考文档回答（开卷）由来与发展
为什么产生（2020 - Facebook AI）：LLM 有三个致命缺陷——知识截止于训练日期、会编造事实（幻觉）、无法引用来源。Facebook AI Research 在 2020 年提出 RAG 论文，首次将检索和生成整合成一个端到端系统。
发展历程：
- 朴素 RAG（2020-2022）
：问题来了搜一段文本，拼接给模型。简单但容易搜到不相关的内容。 - 高级 RAG（2023）
：加入重排序（Re-ranking）、查询重写（Query Rewriting）、混合检索（关键词 + 语义）。检索质量大幅提升。 - Graph RAG（2024）
：不只是搜文本块，而是构建知识图谱，让模型理解实体之间的关系。 - Agentic RAG（2025）
：Agent 自己决定搜哪些资料、搜几轮、怎么整合。多步检索 + 交叉验证。
解决了什么问题
- 消除幻觉
：回答有据可查，每句话都能标注出处 - 实时更新
：知识库更新，模型回答自动更新，无需重新训练 - 领域定制
：上传公司文档，模型变成领域专家 - 可解释性
：用户可以查看引用的来源，判断可信度
不足
- 检索质量决定回答质量
：垃圾进垃圾出。知识库的切分方式、检索算法直接影响结果。 - 多跳推理困难
："A 公司的 CEO 的妻子的生日是哪天"——需要先搜 CEO，再搜妻子，再搜生日。传统 RAG 很难处理好这种链式查询。 - 上下文碎片化
：检索到的多个文档片段可能相互矛盾，模型需要判断采信哪个。 - 延迟增加
：多了检索步骤，响应速度比纯模型推理慢。 - 与实际场景的差距
：生产环境中的文档格式复杂（PDF 扫描件、表格、图表），解析和检索都有挑战。
五、Tool（工具）
是什么
模型可以向外部系统发起调用——搜索网页、执行代码、查询数据库、发送邮件。模型不再只是"说话"，而是能"做事"。
由来与发展
困境（2022）：LLM 很聪明，但被困在对话框里——它知道计算器可以算 123 × 456，但它自己算不对；它知道有天气网站，但它看不到实时天气。
Function Calling 诞生（2023 - OpenAI / Anthropic）：
OpenAI 在 GPT-3.5 Turbo 中率先推出 Function Calling Anthropic 在 Claude 中推出 Tool Use 核心机制相同：模型不直接执行工具，而是输出"请帮我调用 XX 工具，参数是 YY"，由外部代码执行后把结果传回来
演进：
- 单工具调用（2023 上半年）
：一次只调用一个工具 - 并行调用（2023 下半年）
：同时调用多个独立工具（搜天气 + 搜新闻） - 多步调用（2024）
：先搜 A，结果不理想，换个关键词再搜 B - 工具组合（2025）
：搜网页 → 提取内容 → 写代码分析 → 发邮件通知
解决了什么问题
打破了模型的"对话框牢笼"。让模型获得了与现实世界交互的能力——获取实时信息、执行操作、控制设备。
不足
- 工具定义不标准
：OpenAI 和 Anthropic 的工具定义格式不一，代码不能通用 - 工具生态碎片化
：每个开发者都要自己实现一遍"搜索"、"读网页"、"发邮件" - 模型选择工具的准确性
：工具多了以后（如 50+），模型可能选错工具 - 安全边界模糊
：模型调用工具能做"任何事"——删文件、发邮件、转账——谁来把关？
六、MCP（Model Context Protocol）
是什么
Anthropic 在 2024 年底发布的开放标准协议，定义了模型与外部工具、数据源之间的统一通信方式。可以理解为 AI 界的"USB-C 接口"——一个标准，连接万物。
由来与发展
问题驱动：在 MCP 之前，每个 LLM 提供商都有自己的插件/工具接口（OpenAI 的 Function Calling、Anthropic 的 Tool Use、Google 的 Extension）。开发者想同时对接多个模型，或者想让一个工具被多个模型使用，需要写 N×M 份适配代码。
MCP 的架构：
┌─────────┐ ┌─────────────┐ ┌──────────┐│ LLM │ ←──────→ │ MCP Server │ ←──────→ │ 外部资源 ││ (Client)│ MCP协议 │ (标准化服务) │ │ 数据库 ││ │ │ │ │ API ││ │ │ 工具/资源/提示 │ │ 文件系统 │└─────────┘ └─────────────┘ └──────────┘MCP Server 包装了外部资源，通过统一协议暴露三个核心能力：
- Tools（工具）
：模型可以调用的操作（搜文件、查数据库） - Resources（资源）
：模型可以读取的数据（文档、API 响应） - Prompts（提示模板）
：预定义的提示词模板
发展状态：目前由 Anthropic 主导，社区快速跟进。已经有上百个开源 MCP Server（Google Drive、GitHub、Slack、PostgreSQL 等）。
解决了什么问题
- 标准化
：一套接口连接所有模型和所有工具，N+M 问题变为 1×1 - 工具复用
：别人写的 MCP Server 可以直接拿来用 - 解耦
：模型升级不影响工具，工具升级不影响模型 - 安全边界
：MCP Server 运行在独立进程中，权限隔离
不足
- 生态年轻
：标准推出不到一年，覆盖的工具还不够多 - Anthropic 主导
：虽有开放协议，但 OpenAI 和 Google 是否会采纳存疑 - 本地运行为主
：远程 MCP Server 的鉴权、安全、性能还在演进中 - 调试困难
：当 Agent 调用 MCP 工具出错时，很难定位是模型、协议、还是 Server 的问题 - 协议版本兼容
：MCP 本身在快速迭代，已有断代兼容问题
七、Skill（技能）
是什么
给模型预置的一组结构化的"能力包"——包含特定的提示词模板、工具组合、执行流程。把一名通才 LLM 变成某个领域的专家。
由来与发展
概念起源：实际来自实践中的痛点——同一个模型，有些人用得很好，有些人用得很差。差别不在模型，而在于是否有一套可复用的方法论。
从手工到自动化：
- Prompt 模板（2023）
：把好用的 prompt 保存下来分享，"帮我写周报"、"帮我润色英文" - GPTs（2023 底 - OpenAI）
：ChatGPT 商店，用户可以封装自定义 GPT，组合指令 + 知识 + 工具 - Project Instructions（2024 - Anthropic/Claude）
：项目级别的系统提示词和知识库 - Skill 概念（2025）
：更结构化的能力包——不只是一段 prompt，而是包含触发条件、工具链、执行逻辑、输出格式的完整模块
解决了什么问题
- 可复用性
：一套好的方法论可以分享和复制 - 降低门槛
：普通用户不需要学 prompt engineering，直接用别人做好的 Skill - 一致性
：同一类任务每次用相同的 Skill，输出质量和格式保持一致 - 组合性
：多个 Skill 可以组合成更复杂的工作流
不足
- 环境依赖
：一个 Skill 包含的工具在你的环境里可能不存在 - 版本管理
：模型升级后，Skill 的效果可能变化，需要维护 - 上下文占用
：复杂的 Skill 定义本身要占几百到几千 token - "知其然不知其所以然"
：用户依赖 Skill，但不理解背后的原理，遇到边界情况不会处理
八、Agent（智能体）
是什么
一个能够自主感知环境、制定计划、使用工具、执行行动、并从反馈中学习的 AI 系统。核心特征：不是被动回答问题，而是主动完成任务。
由来与发展
哲学根源：Agent 的概念在 AI 领域有 40+ 年历史（可追溯到 1980 年代的 BDI 模型——Belief-Desire-Intention）。但真正的转折点是 2023 年 LLM 的爆发——LLM 提供了"思考能力"，让 Agent 从理论走向实践。
关键里程碑：
- ReAct 范式（2022 - Google/Princeton）
：Reasoning + Acting——模型交替进行思考和行动。看一步、想一步、做一步。这是现代 Agent 的架构原型。 - AutoGPT / BabyAGI（2023 春）
：开源社区爆发了大量"自主 Agent"实验——给模型一个目标，它自己拆解任务、搜索信息、写代码。虽然经常跑偏，但点燃了想象。 - Claude Computer Use（2024 - Anthropic）
：模型可以操作电脑——看屏幕、移动鼠标、点击按钮。 - 工程化 Agent（2025）
：从玩具走向生产。出现了专业的 Agent 框架（LangGraph、CrewAI、AutoGen）。关键在于可靠性——不是"有时候能行"，而是"每次都能行"。
Agent 的四大核心能力：
┌────────────────────────────────────────┐│ Agent ││ ││ 🧠 推理 (Reason) 规划、分解、决策 ││ 🛠️ 工具 (Tool) 搜索、代码、API ││ 💾 记忆 (Memory) 短期/长期记忆 ││ 👁️ 感知 (Perceive) 读取环境反馈 │└────────────────────────────────────────┘解决了什么问题
- 自动化复杂任务
：不再是"对话"，而是"搞定一件事"——帮你订机票、写报告、部署代码 - 减少交互轮次
：传统 LLM 需要用户一步步引导；Agent 接受目标后自己分解和执行 - 串联多个能力
：搜索 + 分析 + 写代码 + 发邮件，Agent 自己编排顺序
不足
- 可靠性的最后一公里
：Agent 在 90% 的情况下表现很好，但剩下 10% 的失败可能造成严重后果（发错邮件、删错文件、下错订单） - Token 消耗黑洞
：Agent 的多轮思考和工具调用会指数级放大 token 消耗，一次任务几百万 token 很常见 - 目标理解偏差
：给 Agent 的目标可能被误解，然后它沿着错误方向全力以赴 - 循环陷阱
：Agent 可能在执行某个步骤时遇到问题 → 换方法 → 再次遇到 → 无限循环 - 可观测性差
：Agent 的内部决策过程像黑箱，出错了很难排查是哪一步的问题
九、Agentic Workflow（智能体工作流）
是什么
不是单个 Agent 单打独斗，而是多个 Agent 协同工作——像一支团队，每个 Agent 有专门的职责，按照预定义的流程协作完成复杂任务。
由来与发展
为什么需要——复杂度天花板：单个 Agent 的能力有限。一个 Agent 既要做研究、又要写代码、又要做 QA，就像让一个人同时当好科学家、工程师和测试员——能行，但做不好。
从单打独斗到团队协作：
单 Agent（2024 初）： 用户 → Agent → 搜 + 查 + 写 + 验证 → 输出 问题：负载过重，容易出错多 Agent / Workflow（2024 中至今）： 用户 → 协调器 ↓ ┌──────┼──────┐ ▼ ▼ ▼ 研究 代码 QA Agent Agent Agent │ │ │ └──────┼──────┘ ▼ 审核 Agent → 输出关键框架：
- LangGraph
：状态机驱动的 Agent 编排 - CrewAI
：基于角色的多 Agent 协作 - AutoGen（Microsoft）
：对话式多 Agent 框架 - AWS Multi-Agent Orchestrator
：云原生 Agent 编排
核心模式：
- Sequential
：A → B → C，流水线式 - Parallel
：A、B、C 同时执行不同任务，结果聚合 - Router
：根据任务类型分发给不同 Agent - Evaluator-Optimizer
：一个写，一个评，循环改进 - Human-in-the-Loop
：关键时刻（花大钱、删文件）先让人审核
解决了什么问题
- 分而治之
：复杂任务拆成子任务，由专业 Agent 处理 - 质量保障
：有专门的评测 Agent，比单 Agent 自己检查自己更客观 - 并行加速
：独立的任务同时执行，总耗时降低 - 可维护性
：每个 Agent 职责单一，修改一个不影响其他
不足
- 编排复杂度
：设计一个好的工作流本身就是一个工程挑战，需要理解任务的内在结构 - 通信损耗
：Agent 之间的信息传递可能丢失细节，错误会在链条中放大 - 成本倍增
：多 Agent = 多倍 token 消耗。简单任务用多 Agent 是大炮打蚊子。 - 过度设计
：很多场景并不需要多 Agent，一个简单的 if-else 就够了。工作流框架被过度使用。 - 调试噩梦
：当 5 个 Agent 协作出错时，要顺着链条一步步排查，找"谁该负责"
十、Feedback（反馈）
是什么
用户或系统对模型输出的评价信息——"这个回答好不好？哪里不好？应该怎么改？"。是模型从"能用"到"好用"的关键。
由来与发展
基础形式——RLHF（2022）：OpenAI 在 InstructGPT 论文中提出——让人来给模型的多个回答排序，用排序数据训练一个"奖励模型"，再让模型学习最大化奖励。ChatGPT 的"会聊天"就得益于此。
从显式到隐式：
- 显式反馈（2022-2023）
："赞/踩"按钮、评分、人工标注。信号强但数据量少。 - 隐式反馈（2023 至今）
：用户是否复制了回答、是否追问、停留时长。噪声大但数据量巨大。 - 过程反馈（2024 至今）
：不只是对最终结果的评价，而是对思考过程、工具选择、搜索关键词等中间步骤的评价。像教练不只告诉你"跳得不够高"，而是说"起跳时膝盖的角度需要调整"。
闭环反馈系统：
用户提问 → Agent 回答 │ ▼ 反馈收集（赞/踩/评分/查看率） │ ▼ 分析引擎（为什么好/不好？） │ ▼ 改进措施（调整 prompt / 切换工具 / 更新知识库） │ ▼ 下次同样的任务 → 更好的回答下一代——Constitutional AI / Self-Improvement：模型不只是被动接收反馈，而是自己用一套"宪法规则"（Constitution）来评估和改进自己的输出。RLHF 让模型听话，Constitutional AI 让模型有原则。
解决了什么问题
- 让模型越来越准
：反馈是模型迭代的唯一驱动力 - 发现盲区
：用户反馈能暴露模型训练的盲区和过时知识 - 个性化
：同一个问题，不同用户期待不同的答案。反馈让模型适应个体偏好 - 安全护栏
：负面反馈（有害、偏见、违规）是安全改进的关键信号
不足
- 冷启动问题
：新系统没有反馈数据，需要人工打样 - 反馈偏见
：少数活跃用户的反馈不能代表全体用户 - 反馈质量参差
：用户说"这个答案不好"，但不说"为什么不好"和"怎么算好" - 反馈滞后
：用户反馈 → 分析 → 改进模型，周期可能长达数周 - 评估困境
：如何评价"反馈是否让模型变好了"？需要标准化的评测基准，但这本身很难设计 - 过度优化风险
：模型学会迎合用户短期的偏好（说得用户爱听的），但失去了长期的帮助性（说用户需要听的）
从基础到前沿：完整进化路径
2020 ─── Prompt Engineering 诞生（GPT-3 In-Context Learning） │2021 ─── Token 优化（BPE/SentencePiece 成熟） │2022 ─── Chain-of-Thought / ReAct（推理+行动） │ RAG 论文（Facebook AI） │ RLHF 落地（ChatGPT） │2023 ─── Function Calling / Tool Use（工具调用） │ Agent 爆发（AutoGPT） │ 上下文窗口军备竞赛（100K+ tokens） │2024 ─── MCP 协议发布（Anthropic） │ Agentic Workflow 框架成熟 │ Skill / GPTs 生态 │ Computer Use（操作电脑） │2025 ─── Agent 从玩具走向生产 │ 多 Agent 协作成为标配 │ 反馈闭环驱动持续学习 │ Context Engineering 系统化一张图总结
┌──────────────┐ │ Prompt │ 人机交互的唯一入口 │ Token │ 信息传递的最小单位 └──────┬───────┘ │ ┌──────▼───────┐ │ Context │ 对话的"记忆空间" └──────┬───────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ RAG │ │ Tool / Skill │ │ 让模型"查资料"│ │ 让模型"做事" │ └──────┬───────┘ └──────┬───────┘ │ │ └───────────────┬───────────────┘ │ ┌──────▼───────┐ │ MCP │ 标准化的"万能插头" └──────┬───────┘ │ ┌──────▼───────┐ │ Agent │ 自主规划、执行、反思 └──────┬───────┘ │ ┌──────▼───────┐ │ Agentic │ 多 Agent 协同工作流 │ Workflow │ └──────┬───────┘ │ ┌──────▼───────┐ │ Feedback │ 从结果中学习，持续进化 └──────────────┘最后更新: 2026-05-24
这些概念仍在快速演进，本文档会持续更新。如有错误或补充，欢迎指正。
