关注腾讯云开发者,一手技术干货提前解锁👇
概念全景图
LLM(大语言模型)
│
│ 厂商通过 HTTP 提供调用能力
▼
LLM API
│
│ 客户端维护对话历史数组
▼
Context(上下文)
│
│ 告诉 LLM "你有哪些工具可用"
▼
Tool Calling(工具调用)
│
│ 加入循环:思考 → 行动 → 观察
▼
Agent Loop(智能体循环)
│
├──────────────┬──────────────┐
▼ ▼ ▼
MCP 协议 Sub-Agent Agent Skill
(标准化工具对接) (分工协作) (流程复用)基础概念
2.1 LLM(大语言模型)
ChatGPT、Claude、Gemini、DeepSeek 等都是 LLM。本质是超大号的"文字接龙"机器——给一段文字,按概率逐词预测下一个词。当参数量达到千亿级别,它就涌现出了写代码、写文章、做数学题的能力。
2.2 LLM API(大模型接口)
LLM 跑在云端 GPU 集群上,厂商通过 HTTP API 提供调用能力:
你的代码 → HTTP POST(带上问题) → LLM 服务 → HTTP 响应(返回回答)2.3 Context(上下文)
LLM 本身是无状态的——每次调用都是一次全新的请求,它不会记得上一句你说了什么。所谓"上下文",就是你随请求一起发过去的所有信息,包括:
第 1 次请求:[消息1] → AI 回复1
第 2 次请求:[消息1, 回复1, 消息2] → AI 回复2
第 3 次请求:[消息1, 回复1, 消息2, 回复2, 消息3] → AI 回复3每次都把完整历史发过去,AI 才能"记住"之前聊了什么。"记忆"不在 AI 脑子里,而在你发送的数组里。
每个模型有上下文窗口(Context Window)限制,比如 128K tokens。超出这个长度,最早的内容就会被截掉。
2.4 Tool / Function Calling(工具调用)
这是从"聊天机器人"进化到"Agent"的关键一步。普通 LLM 只能生成文字,但如果告诉它有个 get_weather 工具,它就能返回结构化的调用请求:
{ "functionCall": { "name": "get_weather", "args": { "city": "深圳" } } }LLM 并没有真的查天气,它只是说"我想调这个工具"。真正执行的是你的代码。LLM 负责"动脑"决策,代码负责"动手"执行。
2.5 AI Agent(智能体)
Agent 是一种架构模式,把上面三者串在一起:
Agent = LLM(大脑) + Tools(手脚) + Loop(驱动循环)2.6 MCP(模型上下文协议)
有了 Tool Calling,Agent 可以调用工具。但每接一个新工具,你都要写一套定义、解析、执行的代码。工具一多,维护成本爆炸。
MCP(Model Context Protocol) 定义了一套统一的协议,让 Agent 能以即插即用的方式对接外部工具和数据源——相当于 AI 世界的 USB 接口标准。
2.7 Sub-Agent(子智能体)
一个 Agent 什么都干,容易出错,上下文也会被塞满无关信息。Sub-Agent 模式是让主 Agent 把子任务委派给专门的小 Agent。每个子 Agent 有自己独立的上下文和专属工具,做完后只把结果交还给主 Agent。
2.8 Agent Skill(技能)
Tool 是单个动作(比如"读文件"),但很多任务是一套固定流程(比如"生成 Git commit"需要:查状态 → 看 diff → 写 commit message → 执行提交)。
Agent Skill 就是预定义好的 prompt + 工具组合——把多个工具和 prompt 打包成一键触发的流程。
2.9 Context Management(上下文管理)
LLM 的上下文窗口是有限的。对话越长,历史消息越多,总会塞满。而且 token 越多,响应越慢、费用越高。
上下文管理就是在"记住足够多"和"别超标"之间找平衡,常见策略包括滑动窗口、摘要压缩、RAG 检索增强。
从零构建 Agent — 四个阶段
整个构建过程分为四个递进阶段,每个阶段解锁一项新能力。
3.1 阶段一:单次对话(API 调用)
最简单的起点——调用 LLM API,让 AI 回答一个问题。
const body = {
messages: [
{ role: "system", content: "你是一个有帮助的助手。" },
{ role: "user", content: "你好" },
],
};
const res = await fetch(apiEndpoint, {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${apiKey}`,
},
body: JSON.stringify(body),
});
const data = await res.json();
console.log(data.choices[0].message.content);关键参数:
系统提示词(system prompt):告诉 AI "你是谁、该怎么做"的隐藏指令,用户看不到,但 AI 会始终遵守。
对话内容(messages):用户实际发送的消息,每条消息带 role(谁说的)和 content(说了什么)。
能力: 单轮问答,关掉程序就全忘。
3.2 阶段二:多轮对话(上下文维护)
LLM 本身不记得上一句你说了什么——每次 API 调用都是一次全新的、独立的请求。解决方案是在客户端维护一个 history 数组,每次请求时带上完整历史:
class Chat {
private history: Message[] = [];
async send(text: string): Promise<string> {
this.history.push({ role: "user", content: text });
const reply = await this.client.sendMessage(this.history, this.systemPrompt);
this.history.push({ role: "assistant", content: reply });
return reply;
}
}每次调 API 都把完整对话历史发过去,LLM 本身是无状态的,"记忆"完全靠客户端的数组模拟。
能力: 多轮对话,但只会"说"不会"做"。
3.3 阶段三:工具调用(Function Calling)
AI 能记住对话了,但它只能"说",不能"做"。给 AI 一双"手"——Tool Calling。
工具注册表——用标准格式描述每个工具:
{
name: "run_shell_command",
description: "Run a shell command on the user's machine...",
parameters: {
command: { type: "string", description: "The shell command to execute" },
},
required: ["command"],
}工具实现:
execute(params: Record<string, unknown>): Promise<unknown> {
const command = params.command as string;
return new Promise((resolve) => {
exec(command, { timeout: timeoutMs }, (error, stdout, stderr) => {
resolve({ exitCode: error?.code ?? 0, stdout, stderr });
});
});
}把工具列表随请求发给 API 后,AI 的回复可能从纯文本变成函数调用请求:
// 纯文本回复
{ "text": "你好!有什么可以帮你的?" }
// 工具调用请求
{ "functionCall": { "name": "run_shell_command", "args": { "command": "ls -la" } } }AI 没有真的执行命令,它只是下达指令,代码负责跑腿。
3.4 阶段四:Agent Loop(ReAct 循环)
有了工具调用能力,但 AI 只能完成"单步动作"。现实任务通常需要多步协作。引入 Agent Loop,即自动化的驱动循环——调完工具看结果,把结果喂回给 AI,让它继续判断下一步。
这个过程通常被称为 ReAct (Reason + Act):
核心循环代码:
async send(text: string): Promise<string> {
this.history.push({ role: "user", content: text });
for (let i = 0; i < MAX_ROUNDS; i++) {
const result = await this.client.sendMessage(this.history, options);
this.history.push({ role: "assistant", content: result });
if (!result.functionCall) {
return result.text ?? "";
}
const { name, args } = result.functionCall;
const toolResult = await this.toolRegistry.execute(name, args);
this.history.push({
role: "tool",
content: JSON.stringify({ name, result: toolResult }),
});
}
throw new Error("Max tool call rounds exceeded");
}实际运行示例:
用户:"帮我看看当前目录有什么文件,然后统计代码行数"
第 1 圈:AI → 执行 ls -la → 代码返回结果
第 2 圈:AI → 执行 wc -l src/*.ts → 代码返回结果
第 3 圈:AI → 返回文本总结 → 循环结束 ✅MAX_ROUNDS 是安全阀,防止 AI 死循环。
3.5 工程化原则
拥有 Agent Loop 后,Agent 已经能自主运行,但要真正可用,还需要关注以下工程化原则。
1. 工具设计:从 "万能胶" 到 "手术刀"
不要只提供一个 run_shell_command 万能工具,而应该设计专门的工具:
工具越"原子化"、越"结构化",Agent 运行的成功率就越高。
2. 上下文注入:给 Agent 戴上 "扩增实境眼镜"
在每轮对话启动前,自动采集环境信息并注入到 Prompt 中:
这样 Agent 一开始就知道自己"在哪里"、"手头有什么",不需要先花一轮工具调用去探索环境。
3. 显示优化:让 "黑盒" 变透明
Agent 在执行工具时,应该给用户清晰的反馈:
interface ToolExecuteResult {
data: unknown; // LLM 需要的结构化原始数据
displayText?: string; // 用户在终端看到的友好提示
}比如执行 shell 命令时显示 $ ls -la,读取文件时显示 Read src/index.ts (lines 1-20),而不是把原始 JSON 甩给用户。
4. 指令优化:从 "聊天" 到 "工作"
系统提示词对 Agent 的行为影响巨大,为开发者工具场景应注意:
进阶架构
4.1 上下文管理
上下文窗口是 Agent 的"工作记忆",但它有硬性限制。对话越长、工具调用越多,token 消耗越快。
为什么需要上下文管理
问题 | 说明 |
|---|---|
Token 限制 | 每个模型有上下文窗口上限(如 128K tokens),超出就截断 |
成本 | Token 数量直接决定 API 费用,历史越长越贵 |
速度 | 输入 token 越多,模型响应延迟越高 |
只保留最近 N 轮对话,丢弃更早的消息。
function slidingWindow(history: Message[], maxTurns: number): Message[] {
if (history.length <= maxTurns * 2) {
return history;
}
const systemPrompt = history[0];
const recentMessages = history.slice(-(maxTurns * 2));
return [systemPrompt, ...recentMessages];
}优点:实现简单,效果直接。 缺点:早期信息完全丢失。
策略 2:摘要压缩
让 LLM 把旧的对话历史压缩成一段摘要。
原始历史(5000 tokens):
用户问了天气 → AI 查了天气 → 用户问了新闻 → AI 查了新闻 → ...
压缩后(200 tokens):
"用户先查了深圳天气(25°C 晴),然后查了今日科技新闻(共 3 条),
接着要求将新闻翻译成英文。"优点:保留关键信息,压缩比高。 缺点:压缩本身消耗 token,且可能丢失细节。
策略 3:RAG 检索增强
不把所有信息都塞进上下文,而是存到外部知识库,需要时按需检索。
用户提问:"上次讨论的数据库方案是什么?"
1. 把问题转成向量 → 去向量数据库检索
2. 找到相关的历史片段 → 注入当前上下文
3. LLM 基于检索结果回答优点:上下文永远保持精简,可以"记住"无限量的历史。 缺点:需要额外的向量数据库基础设施。
策略组合
实际项目中通常组合使用:
┌─────────────────────────────────────────────┐
│ 1. 系统提示词 (始终保留) │
│ 2. 压缩摘要(旧历史) (摘要压缩) │
│ 3. 检索到的相关知识片段 (RAG) │
│ 4. 最近 N 轮对话 (滑动窗口) │
│ 5. 当前用户输入 (始终保留) │
└─────────────────────────────────────────────┘上下文管理没有银弹,需要按场景组合不同策略。
4.2 MCP 协议
每个工具都要写一套"定义→解析→执行"的胶水代码。工具一多,维护成本爆炸。MCP 就是为解决这个问题而生的标准化协议。
MCP 解决的问题
没有 MCP 时:
Agent A 对接 GitHub → 写一套 GitHub 工具定义 + 执行逻辑
Agent A 对接 Slack → 写一套 Slack 工具定义 + 执行逻辑
Agent B 对接 GitHub → 再写一套(跟 A 的还不一样)
...M 个 Agent × N 个工具 = M × N 套集成代码。
有了 MCP:
Agent A ─┐ ┌─ GitHub MCP Server
Agent B ─┤── MCP 协议 ──────┤─ Slack MCP Server
Agent C ─┘ (标准接口) └─ 数据库 MCP ServerM + N 套代码就够了。
MCP 的核心能力
MCP 定义了三种核心原语:
MCP 架构
┌─────────────────────────────────────────────────┐
│ Host │
│ (Agent 应用) │
│ │
│ ┌────────────┐ ┌────────────┐ │
│ │ MCP Client │ │ MCP Client │ ... │
│ └─────┬──────┘ └─────┬──────┘ │
└─────────┼───────────────┼───────────────────────┘
│ MCP 协议 │ MCP 协议
▼ ▼
┌────────────┐ ┌────────────┐
│ MCP Server │ │ MCP Server │
│ (GitHub) │ │ (Database) │
└────────────┘ └────────────┘MCP 通信过程
Agent(Host) MCP Client MCP Server
│ │ │
│ 1. 启动时 │ ── initialize ──▶ │
│ │ ◀── 工具列表 ──── │
│ │ │
│ 2. 用户提问 │ │
│ ──"查 GitHub issue"─▶ │ │
│ │ │
│ 3. LLM 决定调工具 │ │
│ ── tool_call ──────▶ │ ── execute ────▶ │
│ │ ◀── result ───── │
│ ◀── tool_result ───── │ │
│ │ │
│ 4. LLM 生成回复 │ │
│ ◀── 返回给用户 │ │4.3 Sub-Agent 模式
单 Agent 面临两个核心瓶颈:上下文污染(搜索代码的中间结果、测试日志等占满上下文)和任务过杂(需要在不同类型的工作间反复切换)。Sub-Agent 模式通过分工协作来解决这些问题。
Sub-Agent 架构
用户:"帮我调研 React 和 Vue 的优缺点,然后写一个技术选型报告"
┌──────────────┐
│ 主 Agent │ ← 理解任务、拆分、汇总
│(Orchestrator)│
└───────┬──────┘
┌─────────┼─────────┐
▼ ▼ ▼
┌───────────┐ ┌──────────┐ ┌──────────┐
│调研 Agent │ │调研 Agent│ │写作 Agent│
│ (React) │ │ (Vue) │ │ (报告) │
└───────────┘ └──────────┘ └──────────┘每个子 Agent:
Sub-Agent 定义
每个 Sub-Agent 通常由以下元素组成:
name: code-reviewer # 唯一标识
description: "Reviews code..." # 描述信息,用于主 Agent 决策时选择
tools: [read_file, list_dir] # 工具白名单
model: "model-name" # 可覆盖默认模型
maxTurns: 15 # 限制最大工具调用轮数
prompt: | # 专属系统提示词
You are a code reviewer specialized in identifying:
- Security vulnerabilities
- Performance issues
...关键设计要点:
执行流程
主 Agent 决定委派任务
│
▼
1. 根据任务描述选择合适的 Sub-Agent
│
▼
2. 构建受限的工具集(只给白名单中的工具)
│
▼
3. 创建新的 Chat 实例(独立上下文)
│
▼
4. Sub-Agent 执行任务(在自己的 Agent Loop 中)
│
▼
5. 返回结果给主 Agent(只有最终结果,没有中间过程)4.4 Agent Skill
Tool 是单个动作,但很多实际任务是一套固定流程,需要多个 Tool 配合加上特定的 prompt 指引。Skill 就是把这套流程打包成一个可复用的快捷操作。
Skill 的本质
一个 Skill = prompt 模板 + 元数据。
┌─────────────────────────────────────────────────────┐
│ Agent Skill │
│ │
│ 元数据: │
│ name / description / trigger │
│ │
│ Prompt 模板: │
│ 作为 prompt 注入主对话上下文 │
│ 指导 Agent 按步骤执行任务 │
└─────────────────────────────────────────────────────┘Skill 与 Tool、Sub-Agent 的区别
Tool | Skill | Sub-Agent | |
|---|---|---|---|
粒度 | 单个动作 | 一套完整流程 | 独立的子任务 |
触发 | LLM 自动选择 | 用户命令 / LLM 调用 | LLM 调用 |
执行方式 | 直接执行函数 | prompt 注入主对话上下文 | 派生独立 Chat 实例 |
上下文 | 共享主 Agent 上下文 | 共享主 Agent 上下文 | 独立上下文 |
Skill 定义示例
name: commit
description: "Generate a conventional commit message for staged changes"
trigger: /commit
prompt: |
Analyze the staged changes and generate a commit message
following the Conventional Commits specification.
The commit message should:
1. Start with a type: feat, fix, docs, style, refactor, test, or chore
2. Include a scope in parentheses if applicable
3. Have a concise subject line (max 50 chars)
4. Include a body if the change is complex两种触发方式
方式一:用户命令触发
用户直接输入触发命令(如 /commit),系统匹配到对应 Skill,将 prompt 注入对话:
const skillMatch = skillRegistry.match(userInput);
if (skillMatch) {
const injectedPrompt = skillLoader.load(skillMatch.skill, skillMatch.args);
const reply = await chat.send(injectedPrompt);
}方式二:LLM 自主调用
将 Skill 包装成一个 Tool,LLM 在 Agent Loop 中可以自主决定调用:
{
"tool": "skill",
"parameters": {
"skill_name": "commit",
"task": "为当前暂存的更改生成提交信息"
}
}Skill 的价值
场景 | 不用 Skill | 用 Skill |
|---|---|---|
重复性流程 | 用户每次手动描述每一步 | 一条命令一键搞定 |
领域知识 | 用户需要知道具体步骤和参数 | Skill 封装了专家经验,自动执行 |
团队协作 | 每个人的操作方式不一致 | 统一的 Skill 定义保证流程一致性 |
4.5 如何选择:Tool vs Skill vs Sub-Agent
需求来了
│
├─ 是单个原子操作?(读文件、发请求、执行命令)
│ └─ → 用 Tool
│
├─ 是固定流程?(每次步骤一样,只是输入不同)
│ └─ → 用 Skill
│
├─ 需要独立上下文?(中间过程会污染主对话)
│ └─ → 用 Sub-Agent
│
└─ 需要不同模型?(子任务适合用专门的模型)
└─ → 用 Sub-Agent具体场景对照
场景 | 推荐方案 | 理由 |
|---|---|---|
读取一个文件 | Tool | 单个原子操作 |
生成 Git commit message | Skill | 固定流程(查 diff → 写 message → 提交) |
调研某个技术方案 | Sub-Agent | 需要大量搜索,中间结果会污染主上下文 |
执行代码审查 | Sub-Agent | 需要独立上下文,可能需要不同模型 |
格式化代码 | Tool | 单个操作,调用 formatter 即可 |
生成单元测试 | Skill | 固定流程(读源码 → 分析 → 生成测试) |
同时调研 3 个竞品 | Sub-Agent × 3 | 并行执行,各自独立上下文 |
组合使用
实际项目中这三者经常组合使用:
用户输入 /review(触发 Skill)
│
▼
Skill prompt 指导主 Agent 拆分任务
│
├─ Sub-Agent 1:代码审查(使用 read_file Tool)
├─ Sub-Agent 2:安全检查(使用 grep、read_file Tool)
└─ Sub-Agent 3:性能分析(使用 run_command Tool)
│
▼
主 Agent 汇总三个 Sub-Agent 的结果,生成报告总结
本文覆盖了从 LLM 到 Agent 的完整知识体系:
基础概念:
构建过程(四个阶段):
进阶架构:
推荐阅读
-End-
原创作者|cfool
感谢你读到这里,不如关注一下?👇

你对本文内容有哪些看法?同意、反对、困惑的地方是?欢迎留言,我们将邀请作者针对性回复你的评论,欢迎评论留言补充。我们将选取1则优质的评论,送出腾讯云定制文件袋套装1个(见下图)。4月2日中午12点开奖。

扫码领取腾讯云开发者专属服务器代金券!





