AI概率汇总

• LLM
• Agent
• Token
• Context
• Prompt
• MCP

LLM 是服务员的大脑，代表其核心的理解与思考能力；

Token 是你和服务员沟通的字数单位；

Context/Context Window 是服务员的记忆容量，决定它能够记住多少你的需求；

Prompt 是你向服务员下达的指令，包含规则与具体需求；

Tool/MCP 是服务员可以调用的各类工具，例如计算器、后厨、外卖系统等；

Agent/Agent Skill 则对应服务员的角色定位与专业技能，比如专业点餐员搭配智能推荐菜品的能力。

LLM

什么是 LLM

LLM，全称 Large Language Model，翻译过来就是 大语言模型

LLM 的工作原理基本上就是依据极其庞大的数据量的学习来进行「预测下一个字」。

LLM 其实有点像一个"有嘴没手" 的顾问。

LLM 有什么缺点

• 只会「说」不会「做」。

  LLM 的能力被困在对话框里，它没法跟外部世界互动，没法操作任何系统。让他修改代码BUG，它没办法去操作编辑器去改文件、跑测试。

• 没有「记忆」

  LLM 的记忆只限于当前这轮对话的上下文窗口，对话一结束，一切归零。

• 不会用「工具」

  LLM 本身不能上网搜索、不能查数据库、不能调 API，所有回答都来自它「脑子里」已有的知识，这些知识不仅有截止日期，还可能是错的，也就是常说的「幻觉」问题。

• 不会「规划」。

  LLM 是「被动响应型」的，你问一句它答一句，没法自主拆解任务、制定计划、分步执行。

那么有没有一种方式，能让 LLM 不仅会「说」，还能「做」呢？这就是 Agent 要解决的问题。

Agent

什么是Agent

Agent，翻译过来叫智能体。

Agent 就是 LLM 在循环中自主使用工具的系统。

「LLM」说明 Agent 的核心大脑还是大模型，「工具」说明它能调用外部能力，「循环」说明它不是一问一答就结束，而是会不断地思考、行动、观察结果、再思考，直到任务完成。

Agent 怎么解决 LLM 的弊端？

• 针对"只会说不会做"，Agent 引入了工具调用能力，可以调用搜索引擎、数据库、API、代码执行器等各种外部工具来真正执行操作。

• 针对"没有记忆"，Agent 配备了记忆系统，包括记住当前任务上下文的短期记忆，和存储在外部数据库中、可以跨对话保留的长期记忆。

• 针对"不会用工具"，业界推出了 MCP 等标准化协议来统一工具接入方式。

• 针对"不会规划"，Agent 具备了任务拆解和规划能力，能把一个大目标分解成多个小步骤，然后逐步执行。

Agent 的核心组成

一个完整的 Agent 应该是以下四个模块的组合

第一个是大脑，也就是 LLM，负责理解意图、推理判断、决定下一步行动。

第二个是规划模块，负责把复杂任务拆解成可执行的步骤。

第三个是记忆模块，负责存储和检索信息，让 Agent 能在长时间任务中保持连贯。

第四个是工具模块，是 Agent 的「手和脚」，让它能跟外部世界互动。

Agent 和 Workflow 有什么区别？

两者的定义

Workflow 是指 LLM 和工具通过预定义的代码路径进行编排的系统，而 Agent 是指 LLM 动态主导自身流程与工具调用的系统，由 LLM 自主决定如何完成任务。

Workflow 是「我（开发者）告诉你每一步该做什么」，Agent 是「我告诉你目标，你自己决定怎么做」。

Workflow 就像一条工厂流水线，每个工位做什么、零件从哪来到哪去，全都是提前设计好的。工人（LLM）只需要在自己的工位上完成指定动作。

而 Agent 更像一个自主工作的项目经理，老板只告诉他"把这件事搞定"，然后他自己去调研、制定计划、协调资源、推进执行。

核心区别

两者最核心的区别在于**「谁在控制流程」**

Workflow 的控制权在代码手里，流程是确定的、可预测的、可复现的，但灵活性比较差。

Agent 的控制权在 LLM 手里，行为是动态的、灵活的、能适应变化的，但相应地也带来了不确定性。

在实际生产环境中，最常见的其实是混合架构，Workflow 和 Agent 的结合。正如 LangChain 说的："大多数生产中的 Agent 系统其实是 Workflow 和 Agent 的组合。"

Agent有什么工作模式

模式一：ReAct（边想边做）

ReAct 是目前最经典、最基础的 Agent 工作模式，名字来源于 Reasoning + Acting 的缩写，也就是「推理 + 行动」。几乎所有主流的 Agent 框架底层都在用它。

核心思想非常简单：Agent 在思考和行动之间不断交替。具体来说就是一个三步循环，先是思考（Thought），分析当前情况决定下一步做什么；然后是行动（Action），调用一个工具来执行；接着是观察（Observation），查看工具返回的结果。然后回到思考，如此循环，直到任务完成。

模式二：Plan-and-Execute（先想好再做）

它把 Agent 的工作分成两个阶段：第一阶段是规划，Agent 先把完整的执行计划想清楚；第二阶段是执行，按计划逐步完成，不用每步都重新思考全局。

这种模式最大的优势是规划只做一次，执行阶段不用反复推理。

但缺点是不够灵活，如果执行到第 3 步发现情况变了，原来的计划可能就不适用了。所以也有这么个做法是在执行过程中加入「重新规划检查点」，每隔几步检查一下计划是否还靠谱。

模式三：Reflection（做完再检查）

反思模式的核心思想是 Agent 完成任务后不急着交付，而是先自我检查一遍，就像你写完文章不会直接发出去，而是再通读一遍、改一改、润色一下。

实现方法有两种

• 自我反思，同一个 Agent 完成任务后切换到「审查者」角色来审视自己的输出，发现问题就修改，然后再审查，直到满意
• 双 Agent 对话，一个 Agent 负责生成，另一个负责评审，两者来回迭代直到评审方满意，就像代码的 Code Review 过程。这种模式特别适合对质量要求高的场景，比如代码生成、法律文书、学术论文等

模式四：Multi-Agent（团队协作）

Multi-Agent 模式让多个专业化的 Agent 各司其职，比如一个负责规划、一个负责搜集信息、一个负责写代码、一个负责测试，通过协作来完成复杂任务

Anthropic 提醒过：不要过早引入多 Agent 架构。很多时候，一个强大的单 Agent 就够用了。只有任务确实需要拆分成多个并行子任务时，多 Agent 才值得引入。

这几种模式不是互斥的，实际中往往是组合使用的。一个多 Agent 系统中，每个 Agent 内部可能用的是 ReAct 模式，整体协作用的是 Multi-Agent 模式，最后还有一个 Reflection 环节来检查质量。

Function Call（函数调用）

「工具调用」，Agent 能查天气、能搜索信息、能操作数据库，这些能力是怎么实现的？

—— Function Call（函数调用）

从「只会说话」到「能做事情」

Function Call 的工作原理

• 第一步，定义函数

• 第二步，模型判断

• 第三步，执行函数

  LLM 自己并不执行函数。它只是输出了「我想调用这个函数，参数是这些」的结构化指令。真正执行函数的是你的应用程序。

• 第四步，生成回答

Function Call 解决了两个核心问题

• 第一个是**"什么时候调用"的判断问题**，LLM 能根据用户的自然语言意图，自动判断需不需要调用工具、调用哪个工具。你不需要写复杂的条件判断逻辑，LLM 自己会推理。

• 第二个是**"传什么参数"的提取问题**，LLM 能从用户的自然语言中提取出结构化的参数。用户说"帮我查一下北京后天的天气"，LLM 能自动提取出 city=北京 和 date=后天。

Function Call 就是 Agent 能力的最底层技术基础

Function Call 和 Agent 的关系

Function Call 是一次性的「单步调用」，LLM 判断需要调用一个函数，调用完就结束了。

Agent 是「循环调用」，Agent 在一个循环中反复使用 Function Call，每次调用后观察结果，再决定下一步要不要继续调用其他函数。

Function Call 是 Agent 的「原子操作」，Agent 是 Function Call 的「高级编排」。一个 Agent 完成一个复杂任务，可能需要连续进行十几次 Function Call。

MCP

Function Call 让 LLM 能调用工具。但随着 Agent 越来越强大，需要连接的工具和服务越来越多，一个新问题浮出水面了，集成太麻烦了。

Function Call 的集成困境

用 Function Call 的方式，你需要为每一个服务单独写适配代码，为 Slack 写一套函数定义和调用逻辑、为 Google Drive 写一套、为 GitHub 写一套、为数据库又写一套。

如果你有 N 个 AI 应用，要对接 M 个外部服务，就需要写 N × M 个定制集成。

MCP 的诞生

Anthropic 在 2024 年 11 月开源了 MCP（Model Context Protocol，模型上下文协议）。可以把 MCP 理解为**「AI 界的 USB-C 接口」**

它提供了一个统一的标准，让任何 AI 应用都能用同一种方式连接任何外部工具和数据源。

MCP 是怎么工作的？

MCP 的架构主要有三个角色。

• MCP Host（宿主），就是你使用的 AI 应用，比如 Claude Desktop、Cursor 编辑器、你自己开发的 Agent 应用。它是整个交互的发起方。
• MCP Client（客户端），它住在 Host 里面，负责跟 MCP Server 通信。你可以把它理解为"翻译官"，Host 想要什么能力，Client 就去跟对应的 Server 沟通。
• MCP Server（服务端），它负责对外暴露具体的工具能力和数据资源。比如有一个 GitHub MCP Server，它能提供"搜索代码""创建 Issue""查看 PR"等工具。一个 Slack MCP Server 能提供"发送消息""搜索频道"等工具。

用户在 AI 应用中提问 → AI 应用（Host）通过 MCP Client 发现有哪些可用工具 → AI 决定调用某个工具 → MCP Client 向对应的 MCP Server 发送请求 → Server 执行操作返回结果 → AI 基于结果生成回答。

MCP 解决了什么问题？

最核心的就是把 N × M 的集成问题变成了 N + M 的问题。

以前每个 AI 应用要跟每个服务单独对接，现在每个 AI 应用只要支持 MCP 协议（实现一次 Client），每个服务只要提供一个 MCP Server（实现一次 Server），双方就能自动对接。

新增一个服务不需要改任何 AI 应用的代码，新增一个 AI 应用也不需要改任何服务的代码。

而且 MCP Server 暴露的工具是可发现的，AI 应用启动时能自动查询有哪些 MCP Server 可用、每个 Server 提供哪些工具、每个工具的参数是什么。

这意味着 Agent 可以在运行时动态发现新的能力，而不是只能用开发者写死的那些函数

Skills（技能）

Function Call 让 Agent 能调用函数，MCP 让 Agent 用统一标准连接工具

Agent 知道怎么调用工具了，但它知道在什么场景下该用什么方法来解决问题吗？

Skills 是什么

Skills 是一种自然语言指令文件，通常是 Markdown 格式，用来教 Agent"在什么场景下、按照什么方法、遵循什么规范来完成特定任务"。

在 Claude Code、Cursor 等 AI 工具中，Skills 通常以 SKILL.md 文件的形式存在。

Skills 的结构很简单：顶部有一段 YAML 格式的元数据，声明这个 Skill 什么时候应该被激活（比如"当用户要求代码审查时"）；下面是具体的行为指令，用自然语言写成。

---
name: Code_Review_Expert
description: 当用户要求进行代码审查时，自动触发此技能。
triggers:
  - "帮我 review 一下这段代码"
  - "代码审查"
---

# 身份设定
你是一个拥有 10 年开发经验的资深后端架构师，你极其看重代码的可读性、性能和安全性。

# 审查工作流
当你进行代码审查时，你必须严格按照以下步骤进行排查：
1. 看结构：检查代码是否符合单一职责原则，有没有超过 100 行的超长方法。
2. 查漏洞：重点检查是否存在 SQL 注入风险、越权访问风险或空指针异常风险。
3. 审性能：是否有在 for 循环里查数据库的愚蠢操作？是否有流对象没有及时 close 释放？
4. 给方案：你绝对不能只挑毛病，必须针对每个问题给出具体的修改建议，并且附带优化后的代码片段。

# 输出规范
语气要专业、极其直接，不要说废话。直接输出一份 Markdown 格式的审查报告，分点列出问题和修改方案。

MCP 解决的是"能做什么"的问题，Skills 解决的是"该怎么做"的问题

Skills 的工作方式

Skills 的工作方式跟 Function Call 和 MCP 有本质不同。

Function Call 和 MCP 都是让 Agent "执行外部操作"，调用 API、查询数据库、发送消息，这些操作发生在 Agent 外部。

而 Skills 完全在 Agent 内部运行，它不调用任何外部服务，而是被加载到 Agent 的上下文窗口中，改变 Agent 的思考和行为方式。

具体来说，当 Agent 启动时，它会扫描可用的 Skills 列表。当用户提出请求时，Agent 判断有没有匹配的 Skill。如果有，Agent 就把这个 Skill 的内容加载到上下文中，然后按照 Skill 中的指令来思考和行动。

这就像给 Agent 「临时注入了一段专业经验」。没加载 Skill 之前，Agent 只有通用能力；加载了特定 Skill 之后，Agent 在这个领域就变成了专家。

Skills 有什么价值？

Skills 的核心价值在于将专业知识和最佳实践编码成可复用的模块。

Function Call、MCP、Skills 有什么区别？

Agent 是一个新入职的员工。

Function Call 就是"打电话的能力"，MCP 就是"公司的通讯录和电话系统"，Skills 就是"岗位培训手册"

三者的区别体现在几个维度上

从解决的问题来看

• Function Call 解决的是"LLM 怎么跟外部函数交互"这个最基础的问题。

  • MCP 解决的是"怎么用统一标准管理大量工具"的集成问题。
  • Skills 解决的是"Agent 怎么获得领域专业知识"的知识问题。

从运行位置来看

• Function Call 的函数在你的应用程序中执行。
• MCP 的工具在外部的 MCP Server 中执行。
• Skills 完全在 Agent 的上下文窗口内生效，不涉及任何外部调用。

从技术本质来看

• Function Call 是一种 API 协议，LLM 输出结构化的调用请求，应用程序执行后返回结果。
• MCP 是一种通信标准，定义了 Client 和 Server 之间如何发现和调用工具。
• Skills 是一种提示词扩展，用自然语言编写的行为指令，加载到 Agent 的上下文中。

从标准化程度来看

• Function Call 在各 LLM 厂商之间格式不统一（OpenAI 和 Anthropic 的格式就不一样）。
• MCP 是统一的开放标准，跨厂商通用。
• Skills 目前还没有统一标准，各个 Agent 平台有自己的 Skill 格式。

三者是什么关系？

Function Call 是底层基础。MCP 建立在 Function Call 之上，提供了标准化的包装。当你的 Agent 通过 MCP 调用一个工具时，底层其实还是在做 Function Call，只不过格式和通信方式被 MCP 统一了。

A2A

如果有多个 Agent 需要互相协作，它们之间怎么通信？

为什么需要 A2A？

当一个新员工入职时，需要 HR Agent 处理入职手续、IT Agent 配置工作电脑和账号、财务 Agent 设置薪资账户。这三个 Agent 需要协作，但它们互相不认识，也不知道对方会什么、怎么沟通。

MCP 解决不了这个问题，因为 MCP 是给 Agent 连接"工具"用的，它处理的是"Agent 调用数据库""Agent 发送邮件"这类 Agent 与工具之间的交互。

但 Agent 与 Agent 之间的协作，需要一个全新的协议。

什么是 A2A 协议？

A2A 是 Google 在 2025 年 4 月的 Google Cloud Next 大会上发布的一个开放协议，全称 Agent-to-Agent Protocol，顾名思义就是"Agent 对 Agent"的通信协议。它联合了超过 50 家合作伙伴共同推出，包括 Atlassian、Salesforce、SAP、MongoDB、LangChain 等业界大玩家。

A2A 定义了一套标准，让不同的 AI Agent 能够互相发现、互相通信、互相委派任务，不管这些 Agent 是用什么框架开发的、运行在什么平台上。

A2A 的核心概念

• Agent Card（智能体名片）

  每个支持 A2A 的 Agent 都会发布一个 JSON 格式的"名片"，描述自己的身份、能力、擅长的领域、支持的交互方式、认证要求等信息。其他 Agent 通过读取这个名片来了解"这个 Agent 会什么，我能请它帮什么忙"。这就像你在 LinkedIn 上看到一个人的简历，知道他的技能和经验后，才决定要不要跟他合作。

• 任务（Task）

  A2A 中的所有协作都围绕"任务"展开。一个 Client Agent（发起方）创建一个任务，发送给一个 Remote Agent（执行方）。任务有完整的生命周期，从创建、处理中、到完成或失败，每个状态变化都有明确的定义。这让双方能清楚地跟踪任务进展。

• 消息和制品（Message & Artifact）

  Agent 之间通过消息来沟通过程中的信息，通过制品来传递最终结果。比如一个研究 Agent 完成分析后，会把分析报告作为制品返回给请求方。

**A2A 和 MCP 是什么关系？

MCP 是「竖向」的，处理 Agent 到工具的连接；A2A 是「横向」的，处理 Agent 到 Agent 的协作。

Google 的官方设计中，两者是互补的关系，被明确设计为可以共同使用。在一个典型的多 Agent 系统中，一个编排 Agent 通过 A2A 协议把任务委派给不同的专业 Agent，而每个专业 Agent 内部通过 MCP 来连接它自己需要的工具。

协议的边界很清晰：Agent 之间的通信走 A2A，Agent 调用工具走 MCP。

目前整个 Agent 协议生态正在形成一个清晰的分层格局：Function Call 提供底层调用能力，MCP 标准化 Agent 与工具的连接，A2A 标准化 Agent 与 Agent 的协作

---

Agent 相关的核心概念-万字长文图解