先记住三个公式

LLM应用 = Harness承载的Agent循环

Agent = LLM + Instructions + Tools + 循环与停止条件

Context = Prompt + 对话历史 + RAG 资料 + 工具结果 + 被选中的记忆

用一张表掌握核心概念

概念	一句话定义	容易混淆的边界
LLM	根据当前输入，逐步预测后续Token的模型	不是数据库，也不会自己执行程序
Token	模型处理文本的基本切分单位	不等于字数或单词数
Context	本次模型调用能够看见的全部内容	不等于长期记忆
Prompt	发给模型的指令、问题、示例和约束	Prompt只是Context的一部分
RAG	先检索材料，再把相关片段放进Context	不是训练模型，也不是让模型永久记住资料
Function call	模型生成“调用什么函数、传什么参数”的结构化请求	模型只提出调用，外部程序负责真正执行
MCP	连接 AI Host 与外部工具、资料和提示模板的标准协议	不是 Agent，也不是工具本身
Skill	可复用的专业工作包：指令、流程、脚本、模板、参考资料	Skill 教“怎么做”，Tool 提供“能做什么”
Agent	为完成目标而反复观察、决策、调用工具和检查结果的系统	不是单独一次 LLM 调用
Harness	让整个 Agent 安全、可靠运行的宿主与编排层	不是统一标准；在不同系统中范围会有差异

1、LLM：大脑，但不是完整员工

LLM 可以理解成一个“被压缩进参数里的语言与模式预测器”。它的基本工作是给定前面的文本，它会预测下一个最可能出现的 token，并不断重复这个过程，最终生成整段回答。这种机制看似简单，却能表现出总结、翻译、写代码、规划和推理能力。

但要记住三个限制：

• LLM生成的是“高概率答案”，不天然等于事实。
• 它只知道训练参数和当前Context中可见的信息。
• 它本身不会真的查询数据库、发送邮件或修改文件。

因此：

LLM ≈ 大脑
Agent ≈ 能完成任务的员工
Harness ≈ 员工所在的工作环境与管理制度

2. Token：模型世界里的“字符积木”

模型不是直接按“汉字”或“单词”阅读，而是先通过tokenizer把内容切成Token。

Token影响三件事：

• 容量：Context window最多容纳多少Token。
• 成本：API输入和输出通常按Token计费。
• 速度：输入越长、输出越多，通常越慢。

一个常见误解是“128K Context 就等于模型拥有长期记忆”。实际上，它只意味着某次调用最多能放进大约这么多 Token；不在窗口中的信息，模型就看不到。

3. Context：模型当前桌面上的全部材料

Context是本次推理时，真正交给模型的所有内容，可能包括：

系统规则
+ 开发者指令
+ 用户 Prompt
+ 对话历史
+ RAG 检索片段
+ 可用工具的定义
+ 之前的 function call
+ 工具执行结果
+ 当前任务状态

Context 越长也不一定越好。无关内容会增加成本、延迟和干扰，因此优秀的系统追求的是“相关 Context”，不是“最大 Context”。

4. Prompt：对模型工作的具体说明

一个实用 Prompt 通常包含六部分：

角色：你是谁

目标：要完成什么

背景：已知信息是什么

约束：哪些事情不能做

格式：结果应该怎样呈现

验证：输出前检查什么

与 Prompt Engineering的不同是什么？

Prompt 是给模型的具体输入；Prompt Engineering 是系统地设计、测试和改进这些输入的方法。这六部分组成的具体文字是 Prompt；决定采用这六部分、分析为什么需要它们并持续测试优化，是 Prompt Engineering。

发现原 Prompt 的问题、明确使用场景、设计结构、加入约束和格式、使用真实合同测试、统计错误并继续调整的全过程，才叫 Prompt Engineering。

Prompt Engineering通常包含以下工作：

明确任务
→ 分析失败方式
→ 设计 Prompt
→ 准备代表性测试用例
→ 运行模型
→ 评价准确率和稳定性
→ 修改 Prompt
→ 回归测试

设计模型的输入环境和输出契约，使其在一组真实任务上表现得更可靠。

5. RAG：给模型开卷考试

5.1 什么是RAG？为什么需要RAG？

检索增强生成（Retrieval-Augmented Generation），将大模型与外部知识库结合，通过检索补充大模型知识，生成更准确的答案。主要解决大模型知识更新慢、幻觉问题，适用于知识密集型任务。

它将文档切分成小块，转化为向量存储在知识库中。当用户提问时，系统先通过向量检索找到与问题最相关的文档片段，再交给大型语言模型（LLM）生成自然语言回答。RAG结合了检索与生成，灵活性更强。

5.2 RAG的工作流程：

可以概括为两个阶段：离线知识入库和在线检索生成。

一、离线知识入库

离线阶段的目标是把各种原始文档处理成可以被快速检索的知识索引。

1、文档接入

系统接入不同格式的知识文档，包括：PDF、Word、PPT、Excel、Markdown 等文本文件

2、文档解析

系统对文档进行结构化解析，提取其中的有效内容。根据文档类型，可能需要使用：

• OCR：识别扫描件中的文字
• 布局识别：还原标题、段落和页面结构
• 表格识别与表格摘要
• 图片识别与图片摘要
• 父子结构：保留章节、段落和知识片段之间的层级关系
• 知识切片：把长文档拆分成适合检索的 Chunk

这一步的关键不是简单地把”把文档转成纯文本“，而是尽可能保留原文的语义和结构。

3、建立索引

文档解析完成后，系统对知识片段进行处理：利用分词器建立全文索引，使用 Embedding 模型生成向量，建立向量索引。

最终将文本、向量、来源和结构信息存储到数据库中。

二、在线检索与生成

在线阶段的目标是根据用户问题，从知识库中找到可靠依据，再让大模型组织答案

1、接收用户问题

用户提交问题后，首先进行查询转换

2、查询转换

查询转换用于让用户问题更适合检索，可能包括：

• 消除指代和歧义
• 补全对话上下文
• 将口语问题改写成检索表达
• 将复杂问题拆成多个子问题
• 生成多条不同角度的检索 Query

多轮 Query 改写尤其适用于连续对话。

转换后的Query进行向量化。

3、混合检索

向量化后的Query进入混合检索，同时执行：

• 全文检索：根据关键词、词频和字段匹配查找内容
• 向量检索：根据语义相似度查找内容

全文检索擅长关键字查找；向量检索擅长处理同义表达和语义相近的问题。二者结合能够兼顾精确匹配和语义召回。

4、融合排序与相关性判断

两路检索通常会产生不同的候选结果，因此需要进一步排序：

• 使用 RRF 等方法融合全文和向量检索排名
• 使用重排模型对候选片段重新打分
• 根据相关性阈值过滤无关内容
• 去除重复、冲突或质量较差的片段

5、Prompt组装

检索到可靠内容后，系统将这些内容与用户问题、系统规则等一起组装成最终 Prompt。

6、大模型生成

大模型根据组装后的 Prompt 生成最终答案。生成阶段还可以根据业务需要进行：

• 模型选择或模型切换
• 是否启用深度推理
• 角色设定
• 多文档综合回答
• 引用来源标注
• 答案溯源
• 无法回答时的隐式兜底

7、返回用户

系统将生成结果和引用来源返回给用户，形成完整的问答闭环。

5.3 RAG系统的组成：

• chunk（切块）
• Embedding（向量化）
• vector database（向量数据库）
• retrieval（检索）
• generation（生成）

5.4 文本切分的方法：

固定大小切块、滑动窗口切块、基于句子分块、递归分块。

切分为了保证向量化后语义粒度合理，提升检索精度。

5.5 RAG与微调的区别：

RAG通过外部知识库增强，适合动态更新知识场景；不改变模型参数。

微调直接改变模型参数，适合特定任务，但更新成本高。

5.6 评估RAG系统性能：

分为自动化评估与人工评估

自动评估（RAGAS框架）：

• Faithfulness（忠实度）
• Answer Relevance（答案相关性）
• Context Recall（上下文覆盖率）
• Context Precision（上下文准确率）

人工评估：

业务专家打分

指标：正确率、覆盖度、可用性、用户满意度等

6. Function call：模型提出调用，程序负责执行

原理：

指在语言模型里集成"调用外部函数 / API"的能力。

定义函数 -> 把prompt和工具函数描述（tools）给模型 -> 模型识别意图判断是否调用函数，得到模型回复(json) -> 看模型回复里有没有 tool_calls，有就解析出函数名和参数，去调本地真实函数-> 函数调用API拿到信息 -> 把结果作为额外上下文返回模型 -> 模型综合原始问题 + 函数结果，生成最终回复。

1. 单函数 vs 多函数：多函数靠函数名分发；且当后一个函数依赖前一个结果时，需要多轮 function call。

2. 数据库场景技巧：把表结构塞进 description，让模型生成 SQL，再本地执行。

7. MCP：工具连接领域的“通用接口”

MCP想解决的是：

没有 MCP：
每个 AI Host × 每个外部系统 → 单独开发连接器

使用 MCP：
AI Host ↔ 统一协议 ↔ 各类 MCP Server

7.1 MCP的核心结构

MCP有两个核心角色：客户端与服务端。

MCP服务端 (Tool Provider)：工具的提供者

将一个或多个本地函数（例如，Python函数）包装起来，通过一个标准的MCP接口暴露出去。它监听来自客户端的请求，执行对应的函数，并返回结果。

MCP客户端 (Tool Consumer)：工具的调用者或消费者。

连接到MCP服务端，查询可用的工具列表（自发现），并根据需要调用这些工具。

MCP 主机（MCP Hosts）指的是发起请求的 LLM 应用程序。MCP 客户端（MCP Clients）指的是在主机程序内部的一个对象。

7.2 MCP工具调用流程：

步骤一：客户端注册并连接 MCP Server

• MCP Client 启动后，根据配置文件或命令参数连接多个 MCP Server。

• 每个 Server 都会返回一份工具描述列表（Tool Manifest）

• Client 将这些工具的元信息缓存并上报给 LLM，使大模型“知道”有哪些可用工具。

步骤二：LLM 接收用户输入并决定调用工具

• 用户输入请求（如：“帮我查一下 users 表中有多少行数据”）。

• LLM 分析语义后，判断需要使用 query_mysql 工具。

• LLM 生成 function calling 格式的调用指令

步骤三：MCP Client 执行工具调用

• MCP Client 收到该调用后，匹配到对应的 Server。

• 按协议通过 stdio 或 WebSocket 将请求发送给 MCP Server

步骤四：MCP Server 执行工具逻辑

• MCP Server 内部执行工具逻辑。

• 将结果通过相同的通信通道返回给 MCP Client。

步骤五：结果回传给 LLM

• MCP Client 接收结果，并包装为 ToolMessage 发送回 LLM。

• LLM 读取结果上下文，再生成最终自然语言回答

7.3 MCP的通信传输方式

MCP传输方式与MCP协议本身无关，目前主要有三种通信传输方式：stdio、基于HTTP的SSE和Streamable。

（1）stdio (标准输入/输出)

• 类型：stdio一种非常经典和简单的进程间通信（IPC）方式。客户端启动服务端作为一个子进程。

• 工作原理: 客户端通过写入子进程的 标准输入 (stdin) 来发送请求，并通过读取子进程的 标准输出 (stdout) 来获取响应。这种方式简单高效，无需网络开销。

（2）SSE (Server-Sent Events)

• 类型：SSE 是一种 基于 HTTP 的单向推送协议 ，它允许服务器在保持连接开放的情况下，持续向客户端发送事件流。

• 工作原理：客户端发起一个 HTTP 请求，服务器接收请求并保持连接，然后以 text/event-stream 格式将响应数据流式传输给客户端。这在 MCP 中被用来实现请求与响应的通信。

（3）Streamable

• 类型：Streamable-HTTP 是 MCP 提供的另一种基于 HTTP 的传输方式，它同样用于网络通信。

• 工作原理：客户端通过 HTTP 请求与服务器通信。与 SSE 的主要区别在于其传输格式和机制可能有所不同，比如Streamble的传输格式可以为任意格式，而SSE为特定格式；Streamble的通信方向可以为双向，而SSE只能是单向。

7.4 MCP 与 function call 的关系：

Function call：模型怎样表达“我要调用工具”
MCP：Host 怎样发现、连接和调用外部工具

8. Skill：把专家经验封装成操作手册

Skill 是给 Agent 使用的、可复用的专业工作包。它把一类任务的操作流程、专业知识、脚本、模板和验证标准封装起来。

Skill 通常包含：

SKILL.md / 核心指令
+ 工作流程
+ 参考资料
+ 脚本
+ 模板
+ 示例
+ 验证要求

假设你每次都这样告诉 Agent：

制作 PDF 时：
1. 先读取原始文档。
2. 使用指定模板排版。
3. 生成 PDF。
4. 把每一页渲染成图片。
5. 检查文字是否裁切、分页是否合理。
6. 发现问题后修改并重新渲染。
7. 最终只交付验证过的 PDF。

这是一段 Prompt。

如果这类任务经常重复，就可以把这套流程封装成 pdf Skill。以后用户只需要说： 请把这份材料整理成正式 PDF。

因此：

Prompt：
告诉 Agent 这一次要做什么。

Skill：
告诉 Agent 这一类任务应该怎样专业、稳定地完成。

安装一个 Skill 后：

• LLM 参数没有改变
• 模型没有被重新训练
• Skill 内容没有永久写入模型
• Skill 不会自己运行
• Skill 不会自动获得新的系统权限
• Skill 本身不等于工具或 API

Skill 的作用是：当 Agent 执行相关任务时，为它提供更专业、更完整、更稳定的运行说明。

补充A2A

MCP 解决 Agent 如何使用工具，A2A 解决不同 Agent 如何发现彼此、委派任务并协作。

最准确的关系：

用户
  ↓
协调 Agent
  │
  ├── function call ──→ 某个具体函数
  │
  ├── MCP ───────────→ 工具、数据库、API、文件
  │
  └── A2A ───────────→ 另一个独立 Agent
                              │
                              └── MCP ──→ 它自己的工具

例如：

旅行规划 Agent
    │
    ├── A2A → 航班 Agent
    │             └── MCP → 航空公司查询工具
    │
    ├── A2A → 酒店 Agent
    │             └── MCP → 酒店数据库
    │
    └── A2A → 行程 Agent
                  └── MCP → 地图和日历工具

A2A的核心对象：

1. Agent Card：Agent 的数字名片

Agent 对外发布一份 JSON 元数据，说明：

• Agent 的名称和描述
• 支持哪些能力
• 提供哪些服务或 AgentSkill
• 服务地址
• 支持的协议接口
• 是否支持流式响应、异步通知
• 认证和安全要求

协调 Agent 可以先读取 Agent Card，再决定是否把任务交给它。

A2A AgentSkill：
向外界声明“这个 Agent 能做什么”的元数据

2. Message：一次交流

Message 表示 Agent 之间的一轮沟通，例如：

协调 Agent：
“请为 9 月 20 日上海到北京的行程查询航班。”

航班 Agent：
“请补充期望出发时间。”

Message 由一个或多个 Part 组成。

3. Part：消息的内容单元

Part 可以携带：

• 文本
• 文件 URL
• 内联二进制文件
• 结构化 JSON 数据

因此 A2A 不局限于聊天文字，还可以传递图片、合同、报告和机器可读数据。

4. Task：有状态的工作单

简单问题可以直接返回一个 Message；复杂任务通常会创建一个 Task。

Task 拥有唯一 ID 和生命周期

Task状态表格：

这使 A2A 很适合：

• 长时间研究任务
• 需要用户补充材料的任务
• 需要授权的任务
• 多轮跨 Agent 协作
• 可以取消、恢复或查询进度的任务

5. Artifact：Agent 交付的成果

Artifact 是 Task 产生的正式结果，例如：

• PDF 报告
• 旅行计划
• 代码补丁
• 图片
• JSON 分析结果
• 合同草稿

区别是：

Message：交流过程中的话
Artifact：任务最终或阶段性的交付成果

一次完整的 A2A 调用

假设“总协调 Agent”要让“市场研究 Agent”调查某家公司：

1. 获取市场研究 Agent 的 Agent Card
2. 检查它是否声明了公司研究能力
3. 选择双方都支持的接口和认证方式
4. 发送 Message：
   “调查公司 X 的市场规模、竞争对手和风险”
5. 远程 Agent 创建 Task
6. Task 进入 WORKING
7. 研究 Agent 内部使用 MCP 搜索资料
8. 如果缺少地区范围，进入 INPUT_REQUIRED
9. 协调 Agent 补充信息
10. 任务继续执行
11. 研究 Agent 返回进度或流式结果
12. Task 进入 COMPLETED
13. 返回报告 Artifact
14. 协调 Agent 检查并综合最终结果

A2A、MCP、function call、Harness 的区别

Function call
模型表达：“请调用这个函数，并使用这些参数。”

MCP
Agent 表达：“我要使用这个标准化工具或数据资源。”

A2A
Agent 表达：“我要把这个目标委派给另一个独立 Agent。”

Harness
系统负责：“选择调用对象、维护状态、执行协议、控制权限和处理失败。”

A2A 本身并不会自动决定应该委派给谁，也不会替你完成多 Agent 编排。做出委派决策、维护总任务状态和处理失败恢复的，仍然是 Agent 与 Harness。

9. Agent：让模型进入“观察—行动”循环

定义：一种能够感知环境、进行决策、执行动作的智能体。

AI Agent = LLM + 记忆（Memory）+ 任务规划（Planning）+ 工具使用（Tools）

工作流程 5 环：

1. Prompt 提示词：Agent 的初始输入，描述任务（角色范围、任务背景）。

2. LLM 大模型：理解 / 识别 / 选择，是任务规划与推理的核心工具。

3. Memory 记忆：知识库——当前用户输入、上下文、外部向量库、网页信息等。

4. Planning 规划：拆解 / 思考——任务分解、目标设定、路径规划。

5. Action 行动：执行 / 返回——调用工具（计算器、代码解释器、搜索、API 等）。

10. Harness：把所有部件装成可靠系统

Harness 不是一个严格统一的行业标准术语。放在 Agent 语境中，它一般表示承载和编排 Agent 的运行环境。

一个成熟 Harness 通常负责：

• 调用和切换模型
• 组装 Prompt 与 Context
• 截断、总结或压缩历史
• 注册和描述工具
• 验证 function call 参数
• 执行工具并回传结果
• 管理 MCP 连接
• 权限确认与沙箱隔离
• 状态、记忆和任务恢复
• 重试、超时与停止条件
• Token、成本和轮数限制
• 日志、Tracing 和评测
• 单 Agent 或多 Agent 调度

因此可以这样区分：

LLM：做一次推理
Agent：决定接下来做什么
Harness：保证整个过程能够运行、受控、可观察、可恢复

用一个案例串起来

用户说：

检查订单 123 是否符合退款条件；符合的话帮我提交退款。

系统可能这样运行：

1. Harness 接收用户请求。
2. 用户请求成为 Prompt。
3. Harness 加载“退款处理” Skill。
4. RAG 从知识库检索最新退款政策。
5. Prompt、政策片段、工具定义一起进入 Context。
6. 内容被编码为 Token。
7. LLM 判断需要先查询订单。
8. 模型生成 get_order(order_id=123) function call。
9. Harness 通过电商平台的 MCP Server 执行查询。
10. 查询结果回到 Context。
11. Agent 根据订单状态和退款政策继续判断。
12. 如果退款会产生真实影响，Harness 请求用户确认。
13. 模型生成 create_refund(...) function call。
14. Harness 执行并把结果交给模型。
15. Agent 判断任务完成，返回最终说明。