如何快速掌握 Agent 开发：从概念理解到企业级架构落地

很多人刚开始学 Agent，都会有一种很强的割裂感。

明明每个词都好像见过，System Prompt、CoT、ReAct、Function Calling、Tool Use、RAG、MCP、Skills……单独看都能说出一点意思，但一旦把它们放到真实项目里，就很容易乱掉。

有时候会分不清：

• 哪些是提示词层面的设计
• 哪些是执行流程层面的机制
• 哪些又是系统工程层面的能力封装

结果就是术语越学越多，但理解反而越学越碎。

所以，想真正掌握 Agent 开发，最重要的不是死记定义，而是先建立一条清晰主线：

Agent 本质上是一个让大模型先思考、再调用工具、再根据结果继续决策的执行系统。

这篇文章不打算只解释名词，而是想把这些概念真正串起来，尽量从“系统视角”而不是“词汇表视角”去理解 Agent。

一、先别急着背概念，先抓住 Agent 的本质

传统聊天模型更像“问一句，答一句”。

而 Agent 不一样。它不只是回答问题，而是会围绕一个目标完成完整的决策闭环：

1. 理解用户意图
2. 判断是否需要外部能力
3. 决定调用什么工具
4. 获取工具结果
5. 基于结果继续推理
6. 最终完成任务

所以从这个角度看，Agent 的核心不是“会聊天”，而是：

让 LLM 从一个回答器，变成一个可执行、可协作、可扩展的任务中枢。

二、一张图看懂 Agent 的核心主线

先看最重要的一张总图：

flowchart LR
 U[用户请求] --> SP[System Prompt<br/>身份与规则]
 SP --> LLM[LLM推理]
 LLM --> COT[CoT<br/>先分析再决策]
 COT --> REACT[ReAct循环<br/>Thought-Action-Observation]
 REACT --> FC[Function Calling]
 FC --> TOOL[Tool Use]
 TOOL --> SKILL[Skills]
 TOOL --> RAG[RAG检索]
 TOOL --> MCP[MCP远程协作]
 SKILL --> API[本地代码/API/服务]
 RAG --> KB[知识库/向量库/文档库]
 MCP --> Remote[远程服务/其他Agent]
 API --> OBS[Observation 返回结果]
 KB --> OBS
 Remote --> OBS
 OBS --> LLM
 LLM --> A[最终回答]

如果把这张图压缩成一句话，可以先记成：

System Prompt 定规则，CoT 定思考方式，ReAct 定执行循环，Function Calling 定调用格式，Tool Use 定外部能力接入，Skills / RAG / MCP 则负责把能力真正落地。

后面逐个展开时，只要始终沿着这条主线去看，就不会觉得这些概念彼此割裂。

三、先建立底层认知：静态和动态

Agent 开发里，第一个必须建立的视角，其实不是某个技术名词，而是：

哪些东西是静态的，哪些东西是动态的。

这是很多人一开始最容易忽略，但又非常关键的一点。

1. 静态 Model 和动态上下文

模型本身，比如 GPT、Claude 或某个开源模型，这件事相对是静态的。

但在真实 Agent 运行过程中，真正影响输出质量的，往往不是“模型名字”本身，而是动态拼进去的内容，例如：

• 用户当前问题
• 历史对话
• 检索出的知识
• 工具描述
• 上一步执行结果

所以在工程里，模型更像引擎，而真正让系统变强的，是围绕它组织起来的动态上下文。

2. 静态 Prompt 和动态 Prompt

Prompt 也是一样。

静态 Prompt 通常是预先写好的规则，例如：

• 你的身份是什么
• 只能调用哪些工具
• 必须按什么格式返回
• 什么情况下禁止编造

而 动态 Prompt 则是运行时实时拼接的内容，例如：

• 用户问题
• 当前任务状态
• RAG 检索结果
• 工具列表
• 上一步 Observation

所以很多人说“Agent 很大程度上是在做 Prompt 工程”，这句话只说对了一半。更准确地说，Agent 做的是：

动态上下文工程。

四、System Prompt：Agent 的宪法

在整个 Agent 系统里，System Prompt 是最上层的规则。

它不是普通提示词，而是给 LLM 的顶层身份设定和全局边界。它通常在一轮任务开始之前就确定好，并且全程生效。

例如：

你是视频推流智能运维助手，只能调用给定工具，必须按格式输出，禁止编造命令。

这种内容的作用主要有三层：

• 规定身份：你是谁
• 规定边界：你不能做什么
• 规定输出：你要怎么做

它决定的不是“这次任务具体做什么”，而是：

无论用户问什么，你都必须以什么样的方式响应。

如果把 Agent 看成一个国家机器，那 System Prompt 就相当于它的基本法。

五、CoT：让模型先想，再做

很多时候，大模型表现不稳定，并不是因为它不会，而是因为它太容易直接给答案。

这时候就需要 CoT，也就是 Chain of Thought。

它的核心思想并不复杂：

不要让模型立刻回答，而是先显式地分析，再做决定。

例如，你可以在 Prompt 里加入类似要求：

请先分析用户意图，再判断是否需要调用工具，最后给出执行方案。

这样一来，模型就不再是“问到什么就直接说什么”，而是更接近一个会先判断任务类型的执行者。

比如用户说：

10 分钟后帮我开始推流。

理想中的思考路径应该是：

1. 这是一个延迟执行任务，不是立即执行
2. 当前不该直接调用推流接口
3. 应该先调用定时调度工具
4. 等到时间到了，再触发真正执行

这就是 CoT 的价值。它不是让模型“话更多”，而是让模型“先想清楚再动手”。

六、ReAct：让 Agent 真正进入会行动的状态

如果说 CoT 解决的是“怎么想”，那么 ReAct 解决的就是“怎么边想边做”。

ReAct = Reasoning + Acting

它强调的不是一次性输出，而是一个循环过程：

flowchart TD
 T1[Thought 思考当前目标] --> A1[Action 调用工具]
 A1 --> O1[Observation 获取结果]
 O1 --> T2[Thought 基于结果继续推理]
 T2 --> A2[Action 再次调用工具或结束]
 A2 --> O2[Observation]
 O2 --> F[Final Answer]

这其实就是 Agent 最经典的执行框架。

Agent 并不是“想一次，然后结束”，而是：

• 想一小步
• 做一小步
• 看结果
• 再决定下一步

所以 ReAct 才是 Agent 和普通聊天模型之间最关键的区别之一。

七、Function Calling：让调用工具真正可执行

当模型决定要用工具时，不能只在文本里说：

• 我需要查询天气
• 我准备调用数据库
• 我想执行搜索

因为机器程序无法直接执行这种自然语言。

所以这时候需要 Function Calling。

它本质上是让模型以结构化格式返回：

• 要调用哪个函数
• 参数是什么

例如：

{
  "name": "get_weather",
  "arguments": {
    "city": "北京"
  }
}

这样程序才能准确解析，并真正执行。

所以 Function Calling 的本质是：

把大模型的意图变成程序可执行的调用指令。

八、Tool Use：比 Function Calling 更大的概念

很多人会把 Function Calling 和 Tool Use 混在一起，但它们其实不在一个层级上。

可以这样区分：

• Function Calling：是一种调用格式
• Tool Use：是一种能力范式

也就是说：

Function Calling 解决“怎么调”，Tool Use 解决“调什么”。

只要 LLM 使用了外部能力，本质上都属于 Tool Use。

例如：

• 计算器
• 网络搜索
• 天气服务
• 数据库查询
• RAG 检索
• 调用另一个 Agent
• 执行 Shell
• 调用内部业务 API

它们复杂度可能完全不同，但从 Agent 的视角看，都遵循同一个闭环：

flowchart LR
 LLM[LLM] --> Decide[决定调用工具]
 Decide --> Call[发起Tool调用]
 Call --> Result[工具返回结果]
 Result --> LLM

所以 Tool Use 是一个高层抽象，它告诉你：

Agent 的能力，不应该都硬编码在模型里，而应该通过可调用工具不断扩展。

九、Skills：Agent 真正的能力模块

如果说 Tool 是“给模型暴露出来的接口”，那么 Skill 更像是背后真正干活的能力实体。

可以把 Skill 理解成 Agent 的技能库。它通常由两部分组成。

1. 描述层

这是给 LLM 看的，用来告诉模型：

• 这个技能是做什么的
• 什么时候适合调用
• 参数是什么
• 返回什么结果

常见形式可能是 .md 或 .json。

2. 实现层

这是给执行系统用的真实代码，比如 Python 函数、服务接口、脚本模块等。

所以 Skill 并不是一个单独文件，而更像一个：

可被注册、可被描述、可被执行的能力单元。

比如一个常见结构可能长这样：

skills/
  search_skill.py
  weather_skill.py
  rag_skill.py
  agent_collaboration_mcp_skill.py

系统启动时，通常会完成一件很重要的事：自动扫描并注册 Skills。

flowchart TD
 S1[search_skill.py]
 S2[weather_skill.py]
 S3[rag_skill.py]
 S4[agent_collaboration_mcp_skill.py]

 S1 --> REG[SkillRegistry 技能注册表]
 S2 --> REG
 S3 --> REG
 S4 --> REG

 REG --> DESC[拼接技能描述到Prompt]
 REG --> EXEC[按名称路由到真实代码]

所以从某种意义上说，Skill 的描述文件，本质上就是一种动态扩展 Prompt 的机制。

十、RAG：不是让模型记住，而是让模型先查再答

RAG 的本质不是让模型记忆更多，而是让模型回答时不只依赖参数知识，而是依赖外部真实资料。

它的核心流程非常清晰：

flowchart LR
 Q[用户问题] --> R[检索器 Retriever]
 R --> KB[知识库/向量库/文档库]
 KB --> C[返回相关片段 Context]
 C --> P[拼接进Prompt]
 P --> LLM[LLM生成答案]

所以 RAG 解决的是一个非常现实的问题：

模型知道的不一定最新，也不一定准确，尤其是企业内部知识、实时信息、私有文档。

在 Agent 系统里，RAG 常见有两种接入方式：

• 前置检索式：用户提问后先检索，再拼进 Prompt
• Agent 工具式：模型先判断，再决定是否调用 RAG Tool

无论哪种方式，RAG 在 Agent 体系里最终都常常被包装成一个 Tool。

十一、MCP：让 Agent 具备跨系统协作能力

如果说 Tool Use 让模型学会“调工具”，那么 MCP 更像是在解决：

如何用一种标准方式，去调远端工具、远端服务，甚至另一个 Agent。

所以 MCP 更偏协议层和协作层。

它适合解决的问题通常包括：

• 跨语言调用能力
• 跨进程调用服务
• 跨机器访问远端能力
• 多 Agent 之间协作分工

但一定要注意：

MCP 不是 Tool 的替代品，MCP 通常仍然要通过 Tool 的形式暴露给 LLM。

也就是说，从模型视角看，它不关心背后究竟是本地函数、远程服务还是另一个 Agent。它只关心三件事：

• 这个工具能做什么
• 参数怎么传
• 结果怎么返回

所以三者关系可以这样理解：

flowchart LR
 MCP[MCP 协议层] --> TOOL[Tool 调用抽象]
 TOOL --> SKILL[Skill 能力实体]
 SKILL --> SERVICE[本地/远端服务实现]

换句话说：

• MCP 负责“怎么连”
• Tool 负责“怎么调”
• Skill 负责“真正做什么”

十二、把所有概念串成一次真实执行过程

讲到这里，最适合用一个具体例子把这些概念全部串起来。

假设用户说：

10 分钟后启动增强推流。

这个请求在一个企业级 Agent 里，可能会经历下面的完整时序：

sequenceDiagram
 participant User as 用户
 participant Agent as Agent框架
 participant LLM as LLM
 participant Scheduler as 定时任务工具
 participant Stream as 推流服务

 User->>Agent: 10分钟后启动增强推流
 Agent->>LLM: System Prompt + 用户请求 + 技能描述
 LLM->>LLM: CoT分析用户意图
 LLM-->>Agent: Function Calling(schedule_task, time=10min, task=start_stream)

 Agent->>Scheduler: 创建定时任务
 Scheduler-->>Agent: 任务创建成功

 Agent->>LLM: Observation: 定时任务已创建
 LLM-->>Agent: 返回用户确认信息
 Agent-->>User: 已为你安排10分钟后启动增强推流

 Note over Scheduler,Stream: 10分钟后触发执行
 Scheduler->>Stream: 调用 start_enhance_stream
 Stream-->>Scheduler: 推流启动成功

如果你从这个例子回看前面那些术语，就会发现它们其实一点都不散：

• System Prompt 负责设定角色和边界
• CoT 负责分析“这是定时任务，不是立即执行”
• ReAct 负责 Thought → Action → Observation 的执行循环
• Function Calling 负责结构化产出调用指令
• Tool Use 负责调度工具和推流工具
• Skill 负责这些工具背后的具体能力实现

当你能把一个例子完整讲成这样时，说明你对 Agent 的理解已经不是停留在“名词认识”层面了。

十三、企业级 Agent 到底是怎么拼起来的

前面的内容更多是在讲单点概念。真正落到企业项目里，Agent 一般会是一个分层架构。

可以粗略看成下面这样：

flowchart TD
 subgraph L1[交互层]
 U[用户/业务系统]
 end

 subgraph L2[智能决策层]
 SP[System Prompt]
 COT[CoT策略]
 REACT[ReAct执行循环]
 LLM[LLM]
 end

 subgraph L3[能力编排层]
 FC[Function Calling解析]
 TOOL[Tool Router]
 REG[SkillRegistry]
 end

 subgraph L4[能力实现层]
 SK1[本地Skill]
 SK2[RAG Skill]
 SK3[MCP Skill]
 SK4[搜索/天气/API Skill]
 end

 subgraph L5[资源层]
 KB[知识库/向量库]
 API[业务系统API]
 Remote[远程Agent/远端服务]
 end

 U --> LLM
 SP --> LLM
 COT --> LLM
 REACT --> LLM
 LLM --> FC
 FC --> TOOL
 TOOL --> REG
 REG --> SK1
 REG --> SK2
 REG --> SK3
 REG --> SK4
 SK2 --> KB
 SK1 --> API
 SK4 --> API
 SK3 --> Remote
 KB --> LLM
 API --> LLM
 Remote --> LLM

这个图最重要的意义在于，它让你看清楚：

Agent 不是一个单点技术，而是一套“模型决策 + 能力编排 + 工具执行 + 外部资源接入”的组合系统。

真正的企业级 Agent，比起“写几句 Prompt”，更像是在做一个带智能决策能力的微型操作系统。

十四、最容易搞混的几组关系

学 Agent 时，最容易混的就是下面几组概念。

1. Function Calling 和 Tool Use

Function Calling 是调用格式，Tool Use 是调用工具这件事本身。前者更偏协议和结构，后者更偏能力范式。

2. Tool 和 Skill

Tool 更像对模型暴露的“接口形态”，Skill 更像背后真正实现功能的“能力模块”。

可以简单记成：

Tool 是给模型看的入口，Skill 是给系统执行的实体。

3. RAG 和 Tool

RAG 本身是一种检索增强链路，但在 Agent 系统里，通常会被封装成 Tool，因此也会被模型当成一种可调用能力。

4. MCP 和多 Agent

MCP 并不等于多 Agent，但它很适合支撑多 Agent 协作。它解决的是标准化调用和通信，而不是业务逻辑本身。

十五、初学 Agent，真正该怎么学

很多人一上来就钻框架源码，最后被各种抽象层绕晕。其实更好的顺序应该是从“概念链路”开始。

一个更顺的学习顺序是：

第一阶段：先搞清 Prompt 分层

区分清楚：

• System Prompt
• 用户输入
• 动态上下文拼接

第二阶段：理解 CoT 和 ReAct

明白模型不是“直接回答”，而是可以“分析 → 调用 → 观察 → 继续决策”。

第三阶段：掌握 Function Calling

理解大模型如何把意图变成结构化调用指令。

第四阶段：设计自己的 Tool

把外部能力抽象成可调用接口，例如搜索、天气、计算器、知识检索、数据库查询。

第五阶段：构建 Skill 系统

从几个零散函数，过渡到可扫描、可注册、可描述、可维护的技能体系。

第六阶段：把 RAG 接进来

让 Agent 不只依赖模型参数，而具备“先查资料再回答”的能力。

第七阶段：再看 MCP 和多 Agent

当前面的单 Agent 能力链已经理顺，再去看跨系统、跨服务、多 Agent 协作会容易得多。

十六、最后用一句话收住全文

回头看，Agent 开发真正难的，从来不是某个词本身，而是这些词之间的关系。

你可以把整套知识压缩成一句话：

System Prompt 定规则，CoT 定思考，ReAct 定循环，Function Calling 定调用格式，Tool Use 定能力扩展，Skill 负责真正执行，RAG 提供外部知识，MCP 打通跨系统协作。

当这些关系一旦串起来，Agent 就不再是一堆零散术语，而会变成一个非常清晰的系统框架。

十七、适合放在文末的总结图

如果你想在博客最后放一张总览图，可以直接用下面这张：

flowchart TD
 A[System Prompt<br/>身份与边界]
 B[CoT<br/>先分析再决策]
 C[ReAct<br/>思考-行动-观察循环]
 D[Function Calling<br/>结构化调用]
 E[Tool Use<br/>接入外部能力]
 F[Skills<br/>具体能力模块]
 G[RAG<br/>检索外部知识]
 H[MCP<br/>跨系统协作]
 I[API/服务/知识库/远端Agent]

 A --> B --> C --> D --> E
 E --> F --> I
 E --> G --> I
 E --> H --> I

从工程视角看，Agent 并不是某个单一技术点，而是一套围绕 LLM 构建起来的任务执行系统。真正掌握它，关键不在于记住多少术语，而在于能否把这些术语放回同一条执行链路里理解。