当我们聊 Agent 时，我们到底在说什么？

从 LLM、token、prompt 到 RAG、tool calling、memory、orchestration，为初学者画一张从模型到 Agent 系统的概念地图。

刚开始接触 AI 时，最让人头疼的往往不是代码，而是术语。

LLM、token、context window、temperature、tool calling、RAG、embedding、eval、Agent、prompt、harness、skills、MCP、specs、memory，再加上后面很快会碰到的 inference、structured output、session、state、orchestration、sandbox、guardrails、observability，这些词会在你眼前同时冒出来。

它们看起来都很重要，也确实都很重要。问题在于，如果脑子里还没有一张清晰的地图，这些词就会像散落在桌面上的零件一样：每个都认识一点，但始终拼不成一个完整系统。

这篇文章想做的，就是把这些概念重新整理成一张适合初学者的地图。它不追求教科书式定义最严谨，而追求一件更实用的事：当初学者后面继续学习或者拆解各种 Agent 工程项目时，能始终知道自己正在看哪一层、这个概念到底在解决什么问题。

为什么一开始不要急着“做 Agent”

很多人刚接触 AI 时，都会自然地冒出一个想法：我能不能直接做一个 Agent？

这个冲动没有错，但它很容易让人跳过一个关键阶段：先把概念分层。

因为在今天的 AI 工程里，很多词虽然经常被一起提到，但它们其实不在同一个层面上：

有的属于模型本身
有的属于能力扩展
有的属于系统工程
有的属于安全治理和质量保障

如果不先把这些层次拆开，我们就很容易陷入一种典型困境：教程看了不少，术语也见过很多，但一旦真的动手，脑子里仍然是一团模糊的“AI 黑箱”。

所以这篇文章的核心，不是背定义，而是建立一套可复用的理解框架。

第一层：模型层

先从最底层开始。很多概念最后都能追溯到模型层，也就是“模型到底在做什么、怎么做”。

LLM 是什么

LLM 是 Large Language Model 的缩写，中文通常叫“大语言模型”。

最朴素的理解方式是：它是一个在海量文本上训练出来的通用语言系统，能够根据上下文生成接下来最合适的内容。今天常见的 Claude、GPT、Qwen、DeepSeek、Kimi、豆包等，都属于这个范畴。

它之所以重要，是因为它提供了整个 AI 应用的核心能力：

理解自然语言
生成自然语言
解释和编写代码
在一定上下文中做推理和规划

从工程角度看，LLM 解决的是“让机器具备通用语言理解与生成能力”这个问题。它不是完整应用，也不是完整 Agent，但它是一切后续能力的引擎。

token 是什么

token 可以理解成模型处理文本时的基本计量单位。它不完全等于“字”，也不完全等于“词”，更像是模型内部切分文本后的片段。

它之所以重要，是因为几乎所有实际问题最后都会落到 token 上：

成本和计费
上下文容量
响应速度
日志和监控

很多时候，当我们说“这个 prompt 太长了”，本质上是在说：它占用了太多 token。

context 和 context window 是什么

context 是模型当前能看到的全部上下文内容。它不只是用户这一轮的问题，通常还包括：

system prompt
历史对话
工具执行结果
检索回来的知识片段
当前任务状态

context window 则是模型一次最多能处理多少上下文的上限，也就是“上下文窗口”。

这个概念特别关键，因为很多 Agent 系统的问题，最后根本不是“模型不够聪明”，而是“上下文管理不够好”。当上下文太长时，系统就必须做取舍：

删掉什么
总结什么
保留什么
延迟加载什么

换句话说，context window 回答的是“模型一次最多能看多少”，而上下文管理回答的是“在这有限空间里，什么最值得看”。

temperature 是什么

temperature 可以粗略理解为模型输出的发散程度，或者说随机性。

温度低：更稳定、更保守、更可预测
温度高：更发散、变化更多、也更容易跑偏

所以它解决的不是“让模型更聪明”，而是“控制模型输出风格和稳定性”。

如果是写代码、抽取结构化字段、生成配置，通常更偏向低温度；如果是脑暴、文案、创意探索，则可以适度提高。

prompt 是什么

很多人把 prompt 理解成“给 AI 提的问题”，这个理解不算错，但远远不够。

在工程里，prompt 更像一份任务说明书。它往往包含：

角色设定
任务目标
上下文资料
约束条件
输出格式

一个好的 prompt，不是更会说话，而是更会界定边界。它解决的是：如何让模型理解我到底要它做什么。

inference 是什么

inference 通常翻译为“推理”或“推断”，指的是模型真正处理一次请求并生成结果的过程。

你把 prompt 发给模型，模型开始返回内容，这整个过程就是一次 inference。

这个词在工程里很常见，因为它直接关联到：

延迟
成本
并发能力
输出稳定性

所以从产品和系统角度看，inference 不是抽象名词，而是“模型真正开始工作时到底发生了什么”。

单次 inference 的最小链路

用户输入
   ->
prompt 组装
   ->
模型开始 inference
   ->
生成输出 token
   ->
返回结果给用户或程序

system prompt、user prompt 和 assistant message

真正写代码之后，我很快发现：只理解 prompt 还不够，还得理解消息在系统里是怎么组织的。

常见的几类消息包括：

system prompt：系统级规则，定义角色、边界和风格
user prompt：用户这一轮的真实问题或任务
assistant message：模型已经给出的回复
tool_result：工具执行之后返回的结果

这些东西会一起组成模型眼中的 context。也就是说，模型很多时候并不是只在看“你这一轮说了什么”，而是在同时看：

系统让它成为什么样的角色
它前面已经说过什么
工具刚刚做了什么
当前任务推进到了哪里

这也是为什么只做聊天接口和真正做 Agent，复杂度会差这么多。

structured output 是什么

structured output 指的是让模型按照固定结构输出内容，比如 JSON、字段表、特定 schema。

例如，不是让模型自由发挥地回答：

帮我分析这个报错

而是要求它输出：

{
  "root_cause": "",
  "severity": "",
  "next_action": []
}

它之所以重要，是因为自然语言适合给人看，结构化输出更适合给程序消费。很多 Agent 系统之所以能继续自动往下执行，很大程度上就是因为前一步输出足够结构化，后一步才能稳定接住。

第二层：能力扩展层

只有模型本身，我们最多能做一个“会聊天的系统”。但想做真正有用的 AI 应用，就必须让模型接触真实世界、接触外部知识、接触工具和服务。

tool calling 是什么

tool calling 是让模型在需要时主动调用外部工具的机制。

比如模型自己并不知道当前时间、不能直接读本地文件，也不能真的去执行 Shell 命令。但如果你给它注册了工具：

get_time
read_file
run_bash

那么模型就可以在推理过程中决定：“这个问题我需要先调用某个工具，再根据结果继续回答。”

这里有一个非常重要的职责分工：

决定要不要调用工具的是模型
真正执行工具的是你的程序
把工具结果再喂回模型的，还是你的程序

这一步意味着系统从“只会说”进化到了“能行动”。

tool calling 的最小闭环

用户问题
   ->
LLM 判断是否需要工具
   ->
输出 tool call
   ->
程序执行工具
   ->
得到 tool_result
   ->
把 tool_result 塞回 context
   ->
LLM 继续判断
   ->
最终回答 / 继续调用工具

MCP 是什么

MCP 通常指 Model Context Protocol。

如果用工程语言来理解，它更像是一层标准化的连接协议，让模型或 Agent 能以更统一的方式接入外部能力，比如：

文件系统
搜索能力
数据源
外部服务
开发工具

对初学者来说，不一定一开始就要深入协议细节，但可以先把它理解为：一种帮助模型安全、规范连接外部世界的方法。

RAG 是什么

RAG 是 Retrieval-Augmented Generation 的缩写，中文常译为“检索增强生成”。

它的核心思想其实很朴素：先找资料，再生成答案。

比如用户问：“我们公司支付服务的回调字段有哪些？”
如果模型只依赖训练时见过的通用知识，它大概率不知道；但如果系统先去内部文档里检索出相关内容，再把片段拼进上下文，模型就能基于这些资料回答。

RAG 最适合解决的问题包括：

私有知识问答
最新资料问答
模型训练数据之外的问题
需要引用具体文档内容的任务

它不是让模型“更聪明”，而是让模型“在回答前先去看正确的资料”。

RAG 的最小链路

用户问题
   ->
检索器提取关键词 / 向量特征
   ->
从知识库找相关片段
   ->
把片段拼进 prompt
   ->
LLM 基于资料生成答案

embedding 是什么

embedding 通常翻译为“向量表示”。

简单说，它是把一段文本转换成一组数字，让系统可以从“语义相近”的角度比较文本，而不只是按关键词匹配。

比如：

“怎么给用户发重置密码邮件？”
“忘记密码的邮件流程在哪里？”

关键词不完全相同，但意思很接近。embedding 的作用，就是帮助系统识别这种“字不一样，但意思差不多”的关系。

在很多 RAG 系统里，embedding 是检索的重要基础，但它不等于 RAG 本身。RAG 是完整流程，embedding 只是其中常见的一种技术手段。

第三层：系统工程层

当系统开始拥有模型、工具和检索能力后，下一个问题就来了：这些能力怎样才能持续、稳定、可控地协同工作？

这就进入了真正的 Agent 工程语境。

Agent 是什么

Agent 是一个在 AI 领域被说得很多、也经常被说得很神秘的词。

如果从实践角度出发，我更愿意这样定义它：

Agent 不是一个单纯的对话接口，而是一个能够围绕目标持续感知、决策和行动的系统。

一个最小 Agent 往往至少包含这些部分：

一个 LLM
一组可调用工具
一个循环机制
一份持续累积的状态或消息历史
明确的停止条件

所以，聊天接口更像“一问一答”；而 Agent 更像“拿着目标持续做事，直到完成或者停下”。

session 和 state 是什么

session 可以理解成一次持续的会话或任务过程，state 则是这个过程中系统记住的状态。

比如一个 coding agent 在执行任务时，状态里可能包括：

当前在哪个仓库
当前进行到第几步
上次工具调用结果是什么
哪些文件已经改过
当前是成功、失败还是等待确认

只要系统开始跨多步行动，就一定会遇到 session 和 state 管理问题。因为 Agent 不只是“会回答”，而是“会持续做事”。

planning 是什么

planning 就是规划。

任务简单时，模型直接开干可能问题不大；但任务一复杂，直接动手往往很容易走偏。这时系统就会先让模型把目标拆成更小、更清晰的步骤，比如：

先读项目结构
再定位相关文件
再修改实现
再跑测试验证

prompt 更像任务说明，planning 更像执行路线。它解决的是：面对复杂目标，先把路径理顺。

planner、executor、verifier

这三个词在 Agent 应用里特别常见，可以把它们理解为一组典型的职责拆分：

planner：负责分析目标、制定步骤
executor：负责实际执行步骤、调用工具、修改内容
verifier：负责检查结果是否真的达标

有些系统里它们是不同的子代理，有些系统里只是同一个模型在不同阶段扮演不同角色。但背后的思想是一致的：把“想怎么做”“真正去做”“检查做得对不对”拆开。

orchestration 是什么

orchestration 通常可以翻译为“编排”。

如果说 tool calling 解决的是“单次怎么调用工具”，那 orchestration 解决的就是：

多步骤如何衔接
多个 agent 如何分工
哪一步先做，哪一步后做
失败之后如何重试或回滚

它关心的是系统级流程，而不是单个 prompt 的质量。所以一个项目一旦从“单脚本”长成“Agent 应用”，orchestration 通常就会出现。

harness 是什么

harness 这个词在中文资料里并不常见，但在 Agent 工程里非常关键。

你可以把它理解成：围绕模型搭建出来的工作环境和执行框架。

它通常包括：

工具系统
权限控制
文件系统或工作区
任务状态
上下文管理
日志和观察能力

如果说 LLM 是大脑，harness 就更像是大脑工作的身体、手脚和外部环境。很多所谓“Agent 应用开发”，本质上做的其实是 harness 工程，而不是训练模型本身。

skills 是什么

skills 可以理解成一组可复用的能力说明书。它们可能表现为：

一段特定领域的指令
一套约束和流程
某种工具组合的使用方式

比如一个 coding agent 可能会有“代码审查 skill”“写计划 skill”“测试驱动开发 skill”。这些 skill 不一定是代码，也可以是规则文件、模板、结构化提示或说明文档。

它解决的是：如何把经验沉淀成可复用的能力模块。

specs 是什么

specs 指规格说明、需求说明或实现约束文档。

很多 AI 编程失败，不是因为模型不会写代码，而是因为需求本身不清楚。spec 的作用就是把问题前置：

目标是什么
不做什么
输入输出是什么
验收标准是什么

它解决的不是“让文本更华丽”，而是“减少误解，让实现更可验证”。

第四层：治理和质量层

当系统开始真正能行动，另一个问题就变得非常现实：它会不会失控？出了问题我能不能看清？它做出来的东西到底靠不靠谱？

sandbox 是什么

sandbox 指的是让 Agent 在一个受控、隔离的环境里执行操作。

例如：

只允许访问某个工作目录
只允许运行白名单命令
在容器或临时环境里改代码
任务结束后销毁环境

它之所以重要，是因为一旦 Agent 能读文件、改代码、跑命令，你就必须回答一个现实问题：它到底能影响到哪里？

guardrails 是什么

guardrails 可以理解成系统的安全护栏。

比如：

禁止访问敏感文件
禁止执行危险命令
要求输出符合固定格式
高风险操作必须人工确认

prompt 更像“告诉模型该怎么做”，guardrails 更像“即使模型想乱来，系统也要把它拦住”。

observability 是什么

observability 指系统的可观测性，也就是你能不能看清它到底发生了什么。

在 Agent 场景里，它通常包括：

每一步做了什么
调用了哪些工具
花了多少时间
消耗了多少 token
为什么失败
当前卡在哪一步

没有 observability，你只会知道“它没做好”；有了 observability，你才知道它究竟是 prompt 出了问题、检索出了问题、工具出了问题，还是状态机出了问题。

memory 是什么

memory 指系统保留并复用历史信息的能力。

它可以很简单，比如保留最近几轮对话；也可以更复杂，比如：

记住用户偏好
记住项目结构
记住任务阶段
记住之前失败过的尝试

没有 memory，系统每次都像“重新认识你”；有了 memory，它才更像是在连续地工作。

eval 是什么

eval 就是评估。

在传统软件里，我们用测试判断功能对不对；在 AI 应用里，eval 的作用也类似，只不过评估对象变得更复杂。它可能关注：

回答是否正确
工具是否调用对了
格式是否稳定
检索是否命中正确资料
一个 Agent 是否真的完成了任务

如果没有 eval，我们就很容易陷入一种错觉：它看起来像对，所以它应该真的对。可 AI 系统最容易出现的问题，恰恰就是“说得像那么回事，但并没有真正做对”。

从单次调用到 Agent 应用，它是怎么一步步长出来的

如果把这些词按系统生长的顺序重新串起来，我会得到这样一条路线：

最开始，我们只有一次 LLM inference
    ->
为了更稳定地控制输出，我们设计 prompt，并关注 temperature
    ->
为了让程序更容易消费结果，我们引入 structured output
    ->
为了让模型能获取真实世界能力，我们接入 tool calling / MCP
    ->
为了让模型回答私有知识问题，我们加入 RAG 和 embedding
    ->
为了让一次调用变成持续过程，我们开始管理 session 和 state
    ->
为了让复杂目标不至于乱做，我们加入 planning
    ->
为了拆分职责，我们引入 planner / executor / verifier
    ->
为了让多步骤和多角色协同起来，我们需要 orchestration
    ->
为了让系统可控，我们补上 sandbox 和 guardrails
    ->
为了知道系统到底在做什么，我们建设 observability
    ->
最后再用 eval 反过来判断整个系统是否真的有效

这样看下来，Agent 其实不是什么突然冒出来的神秘新物种，它更像是一层层工程能力叠出来的结果。

再看几张链路图

有些概念看文字很容易懂，但过两天也很容易散掉。所以我想用几张图把它们重新钉在一起。

从聊天到 Agent 的能力升级

聊天接口
  只有 prompt + LLM + answer
      ->
工具增强应用
  prompt + LLM + tool calling
      ->
知识增强应用
  prompt + LLM + RAG + memory
      ->
Agent 应用
  prompt + tools + RAG + state + planning + orchestration + eval

Agent 系统的分层图

+------------------------------------------------------+
|                     Agent Product                    |
|      chat UI / task UI / approval / logs / diff      |
+------------------------------------------------------+
|                  Orchestration Layer                 |
|   planner / executor / verifier / workflow / state   |
+------------------------------------------------------+
|                    Capability Layer                  |
|     tool calling / RAG / MCP / skills / memory       |
+------------------------------------------------------+
|                     Model Layer                      |
|   LLM / prompt / inference / temperature / tokens    |
+------------------------------------------------------+
|                Safety & Quality Layer                |
| sandbox / guardrails / observability / eval          |
+------------------------------------------------------+

一个 coding agent 常见的执行闭环

用户提需求
   ->
specs 明确目标和验收标准
   ->
planner 拆步骤
   ->
executor 调工具读文件 / 改代码 / 跑命令
   ->
verifier 跑测试和检查
   ->
observability 记录全过程
   ->
eval 判断结果是否达标
   ->
通过则完成，不通过则回到 planner 或 executor

一条更完整的概念链路

用户提出问题
    ->
Prompt 组织任务和约束
    ->
LLM 发起一次 inference，并在 context window 内理解上下文
    ->
为了让输出更稳定，系统通常还会要求 structured output
    ->
如果需要外部能力，就触发 tool calling / MCP
    ->
如果需要额外知识，就通过 RAG 检索资料
    ->
embedding 帮助做更好的语义检索
    ->
memory 保存长期有价值的信息
    ->
harness 负责把这些能力组织成一个能持续工作的系统
    ->
session 和 state 让系统知道自己进行到了哪里
    ->
planning、planner / executor / verifier 和 orchestration 让复杂任务可以被分解、执行和检查
    ->
sandbox、guardrails 和 observability 让系统变得更安全、更可控、更容易排查
    ->
当系统能围绕目标持续行动时，我们就开始接近 Agent
    ->
最后用 eval 判断它是不是真的有效

把这些词重新放回正确的位置

如果现在让我把这些概念重新归类，我会这样理解：

LLM 是核心能力引擎
prompt、temperature、context、inference、structured output 是模型使用层
tool calling、RAG、embedding、MCP 是能力扩展层
memory、skills、specs、session、state、planning、orchestration、harness 是系统工程层
sandbox、guardrails、observability 是系统治理层
eval 是质量保障层