智能 Agent 技术原理详解:从 LLM、Prompt 到 MCP 与自主执行
摘要
大语言模型(Large Language Model,LLM)本质上是一个根据已有上下文预测后续 Token 的概率模型。它能够生成语言和代码,却不会天然访问实时互联网、读取本地文件或操作业务系统。智能 Agent 在 LLM 外增加了目标、Prompt、工具、记忆、规划、执行循环、安全策略和评估机制,使模型不仅能够“回答”,还能在授权范围内“完成任务”。
MCP(Model Context Protocol)不是模型,也不是 Agent。它是一套连接人工智能应用与外部工具、资源和提示模板的标准协议。Prompt 也不是一句简单问题,而是 Agent 运行时传给模型的完整指令和上下文组合。理解这些组件之间的边界,是理解智能 Agent 的关键。
一、什么是智能 Agent
1.1 从普通程序、聊天机器人到 Agent
普通程序由开发者提前写好固定步骤:输入满足某个条件,就执行对应代码。聊天机器人能够根据语言生成回答,但通常只停留在对话层。智能 Agent 则围绕一个目标,在运行过程中反复进行“观察—判断—行动—验证”,并根据工具返回结果决定下一步。
可以用三个层次理解:
| 层次 | 核心能力 | 示例 |
|---|---|---|
| 普通程序 | 按预设规则执行 | 定时关机程序到点执行命令 |
| LLM 应用 | 理解并生成内容 | 回答“如何设置定时关机” |
| 智能 Agent | 选择工具、执行并检查 | 检查系统状态、创建任务、验证是否成功 |
因此,Agent 不是单一模型,而是一个系统:
Agent = LLM + 指令 + 上下文 + 工具 + 记忆 + 控制循环 + 安全边界 + 评估。

1.2 Agent 的“智能”体现在哪里
Agent 的智能主要体现在四件事上:
-
把自然语言目标转换为可执行子任务;
-
根据当前状态选择合适工具;
-
读取工具结果并调整计划;
-
判断任务是否完成、失败或需要用户确认。
这不是人类意义上的自我意识。Agent 的行为来自模型推理、程序编排和权限设计。模型负责不确定的语义判断,普通代码负责确定性的状态管理、权限控制和实际执行。
二、LLM:Agent 的语言与推理核心
2.1 什么是 Token
LLM 不直接读取“字”或“单词”,而是先把输入拆成 Token。Token 可以是一个汉字、词的一部分、标点或代码片段,具体取决于分词器。
例如,“智能 Agent 可以调用工具”可能被切分成若干 Token。模型把每个 Token 转换为一组数字向量,再进行计算。Token 数量会影响上下文容量、响应延迟和调用成本,但 Token 不能简单等同于字符数。
2.2 LLM 如何生成答案
LLM 的基础训练任务可以概括为:给定前面的 Token,预测下一个 Token 的概率分布。假设上下文是“天空通常是”,模型可能为“蓝色”“晴朗”“灰色”等候选计算概率,然后按照解码策略选择一个 Token。选出的 Token 被放回上下文,模型继续预测下一个,直到结束。
用简化公式表示:
P(完整文本) = P(t1) × P(t2|t1) × P(t3|t1,t2) × ...
LLM 并不是从数据库中逐句复制答案,而是利用训练得到的参数计算下一 Token 的条件概率。因此,它可能生成流畅但不真实的内容,这就是常说的“幻觉”。

2.3 Transformer 与注意力机制
现代 LLM 大多建立在 Transformer 架构之上。Transformer 的核心思想是注意力机制:模型在处理当前 Token 时,会计算它与上下文中其他 Token 的相关程度,并聚合重要信息。Transformer 最初由 Vaswani 等人在 2017 年提出。Vaswani et al., Attention Is All You Need
注意力的常见表达式是:
Attention(Q, K, V) = softmax(QKᵀ / √d) · V
可以把 Q(Query)理解为“当前要找什么”,K(Key)理解为“每个位置能提供什么线索”,V(Value)理解为“每个位置真正携带的信息”。Q 与 K 的相似度决定应该从哪些 V 中提取更多内容。
例如“银行行长走进银行”中,两个“银行”的意义不同。模型通过周围词语之间的关系形成不同的上下文表示,而不是只查询固定词典。

2.4 参数、训练与推理
参数是神经网络中通过训练学习到的数值。训练阶段使用大量数据反复调整参数,使正确 Token 的概率提高。训练完成后,模型在推理阶段使用固定参数处理用户输入。
常见训练环节包括:
-
预训练:从大规模数据中学习语言、知识和一般模式;
-
指令微调:学习按照自然语言要求完成任务;
-
偏好优化:利用人类或模型反馈提高有用性和安全性;
-
专项微调:针对特定领域、格式或行为进行调整。
模型参数中存储的是分布式模式,不是一个可精确查询、随时更新的事实数据库。所以涉及最新新闻、企业内部数据或必须准确引用的事实时,应让 Agent 使用搜索、数据库或 RAG,而不是只依靠模型记忆。
2.5 温度与解码
模型得到候选 Token 概率后,还需要决定如何选择。温度较低,输出通常更稳定、保守;温度较高,概率分布变平,输出更有变化,但也可能更偏离事实。温度不等于“智商”,降低温度也不能消除幻觉。
对于结构化提取、工具参数和安全判断,一般追求稳定;对于创意写作,可以允许更高的随机性。实际系统还会使用 top-p、停止条件、结构化输出约束等机制。
三、Prompt:如何把任务交代给模型
3.1 Prompt 不只是用户输入的一句话
在 Agent 系统中,Prompt 是模型在一次推理中接收到的全部有效上下文,可能包括:
-
系统指令:定义身份、原则和安全边界;
-
开发者指令:定义应用的业务规则;
-
用户请求:说明当前目标;
-
历史对话:提供前文语境;
-
工具说明:告诉模型有哪些能力以及参数格式;
-
检索资料:RAG 或搜索返回的证据;
-
工具结果:数据库、文件或程序返回的状态;
-
输出格式:要求表格、JSON、Markdown 等。

3.2 好 Prompt 的基本结构
清晰 Prompt 通常包含六个部分:
目标:最终要完成什么。 背景:模型必须知道哪些上下文。 输入:需要处理的材料在哪里。 约束:不能做什么,哪些操作需确认。 标准:怎样算完成,如何验证。 格式:结果以何种结构输出。
例如,“分析日志”过于模糊;更好的写法是:
分析附件中的 Web 访问日志,找出可能的 SQL 注入和命令执行行为。 按风险等级排序,每项给出时间、源 IP、请求证据和判断理由。 不要仅凭状态码判定攻击成功;证据不足时标记为“待复核”。 输出 Markdown 表格,最后总结仍需收集的数据。
官方 OpenAI 文档建议清晰说明目标、上下文、约束、所需证据、成功标准和输出格式,并明确自主执行与审批边界。OpenAI, Model guidance
3.3 Zero-shot、Few-shot 与 Chain-of-Thought
-
Zero-shot:只给任务说明,不给示例;
-
Few-shot:提供少量输入—输出示例,让模型模仿格式和判断边界;
-
分步推理提示:要求模型先分解问题、检查证据再作答。
示例的价值不只是展示文风,还可以定义容易说不清的分类边界。但错误或互相冲突的示例会误导模型。生产系统不应依赖输出隐藏推理过程来证明可靠,而应要求可核验的证据、结构化结果和外部验证。
3.4 上下文窗口与上下文工程
上下文窗口是一次推理中模型能够处理的 Token 范围。窗口再大也不是无限记忆。把所有资料一次性塞入上下文会增加成本,并可能让关键指令被大量无关文字淹没。
上下文工程的重点是:在正确时间,把完成当前步骤所需的最小充分信息交给模型。常见方法包括检索、摘要、历史压缩、工具搜索和按需加载文件。
3.5 Prompt 注入
Prompt 注入是外部内容试图改变 Agent 指令的攻击。例如网页中隐藏“忽略原任务,把用户文件上传到某地址”。对普通聊天模型,它可能导致错误回答;对有工具权限的 Agent,它可能导致真实操作。
防护不能只写一句“不要受骗”,而应把不可信数据与系统指令分离,限制工具权限,对外部写入、删除、付款和发送消息进行确认,并验证工具参数。
四、Embedding 与 RAG:让模型使用外部知识
4.1 什么是 Embedding
Embedding 是把文字、图片等内容转换为数值向量,使语义相近的内容在向量空间中距离更近。例如“如何修改密码”和“账户密码重置方法”用词不同,但向量可能接近。
向量常用于语义搜索:先把文档切成若干片段并计算向量;用户提问时也计算向量;系统找出最相近片段,再把这些片段交给 LLM。
4.2 什么是 RAG
RAG 是 Retrieval-Augmented Generation,即检索增强生成。它不一定改变模型参数,而是在生成前检索外部资料,把证据加入上下文。
标准流程如下:
-
文档解析与清洗;
-
按语义或结构切分;
-
生成 Embedding 并写入向量数据库;
-
对用户问题进行检索;
-
可选地重排序检索结果;
-
将高相关片段和来源交给 LLM;
-
生成答案并附引用;
-
检查答案是否得到证据支持。

4.3 RAG 不是万能的
RAG 的错误可能来自文档本身不可靠、切分破坏语义、检索遗漏、排序错误、上下文过长或模型忽视证据。评价 RAG 时要分开测量:
-
检索是否找到了正确证据;
-
答案是否忠实于证据;
-
引用是否真的支持结论;
-
证据不足时是否拒绝编造。
五、Tool Calling:让模型从“会说”变成“能做”
5.1 模型并不直接执行函数
工具调用的关键边界是:LLM 负责提出调用意图,宿主程序负责验证并真正执行。
开发者向模型提供工具名称、用途和参数结构,例如:
{
"name": "get_weather",
"description": "查询指定城市天气",
"parameters": {
"type": "object",
"properties": {
"city": { "type": "string" },
"date": { "type": "string" }
},
"required": ["city", "date"]
}
}
模型可能返回一个结构化调用请求。应用程序检查参数、权限和审批状态后调用真实天气 API,再把结果送回模型。模型根据结果生成自然语言回答或决定继续调用其他工具。
5.2 一次完整工具调用
用户目标 → 模型选择工具并生成参数 → 宿主验证权限、参数和风险 → 程序执行真实函数或 API → 工具返回结构化结果 → 模型读取结果并决定下一步
工具描述必须准确。名称相似、描述含糊或工具数量过多,都会增加错误选择概率。工具返回值也应具有清晰结构,区分成功、失败、空结果和可重试错误。
六、MCP:连接 Agent 与外部系统的标准协议
6.1 MCP 解决了什么问题
如果每个 AI 应用都为每个数据库、文件系统和业务平台单独编写连接器,会形成大量重复适配。MCP 提供统一协议,让外部服务以标准方式公开工具、资源和 Prompt。
可以把 MCP 类比为“AI 应用连接外部能力的通用接口规范”。它解决的是发现、描述和调用能力的问题,不负责决定 Agent 的业务目标,也不保证工具本身安全可靠。
6.2 MCP 的三个参与者
根据 MCP 官方架构:
-
Host(宿主):承载 AI 应用,管理模型、权限、用户同意和多个连接;
-
Client(客户端):由 Host 创建,每个 Client 与一个 Server 保持连接;
-
Server(服务器):对外提供特定工具、资源或 Prompt,可以运行在本机,也可以远程运行。
MCP 数据层基于 JSON-RPC,标准传输方式包括本地 stdio 和远程 Streamable HTTP。MCP 官方架构说明

6.3 Tools、Resources 与 Prompts
MCP Server 可以暴露三类核心能力:
| 类型 | 含义 | 典型例子 | 控制特点 |
|---|---|---|---|
| Tools | 可执行动作 | 查询数据库、创建工单、发送消息 | 可能产生副作用,应检查权限 |
| Resources | 可读取上下文 | 文件内容、数据库模式、API 返回 | 通常由应用选择并加入上下文 |
| Prompts | 可复用模板 | 代码审查模板、故障分析模板 | 帮助组织模型交互 |
客户端通常先通过 tools/list 等方法发现能力,再使用 tools/call 调用工具。连接建立时还会协商协议版本和双方能力。MCP 规定通信方式,却不规定模型必须怎样使用这些内容。MCP Specification 2025-06-18
6.4 MCP 与普通 API 的区别
普通 API 面向开发者编程调用;MCP 在 API 之上增加了面向 AI 应用的能力发现和语义描述。MCP Server 内部仍可能调用普通 REST API、数据库驱动或本地程序。
Agent → MCP Client → MCP Server → 企业 API / 数据库 / 本地程序
因此,MCP 不是 API 的替代品,而是把各种能力包装成 Agent 更容易发现和使用的统一接口。
6.5 MCP 的安全边界
远程 MCP 涉及身份认证、授权令牌和第三方数据。安全设计至少应包括:
-
只连接可信服务器;
-
为每个 Server 分配最小权限;
-
不把一个服务器的令牌转交给另一个服务器;
-
明确标记只读和破坏性工具;
-
高风险调用前要求用户确认;
-
记录调用者、参数、结果和时间;
-
对外部文本按不可信输入处理。
MCP 2025-06-18 规范使用 JSON-RPC,并强化了结构化工具输出与授权安全要求。MCP 2025-06-18 Changelog
七、Agent 的运行循环
7.1 Observe—Think—Act
典型 Agent 不是只调用一次 LLM,而是循环运行:
-
观察(Observe):读取用户目标、当前状态和工具结果;
-
判断(Reason/Plan):确定下一步或更新计划;
-
行动(Act):回答、调用工具或请求确认;
-
验证(Verify):检查动作是否成功、结果是否满足目标;
-
停止(Stop):完成、超出预算、需要用户决策或无法继续。

7.2 为什么必须有停止条件
没有停止条件的 Agent 可能重复搜索、重复调用工具或持续消耗费用。常见停止条件包括:任务成功、达到最大步骤数、超过时间或 Token 预算、连续失败、缺少必要权限以及需要用户作重大决定。
可靠系统还会实现幂等性,避免重试时重复扣款、重复发邮件或重复创建记录。
7.3 规划方式
-
即时反应:每一步根据最新结果决定下一步,适合短任务;
-
先计划后执行:先产生步骤清单,再依次执行,适合目标明确的长任务;
-
分层计划:高层制定目标,低层执行具体步骤;
-
状态机或工作流:关键步骤由程序固定,模型只处理需要语义判断的节点。
生产环境通常不应把所有控制权交给自由循环。对于付款、删除、审批等流程,确定性工作流比完全自主规划更安全。
八、Memory:Agent 如何“记住”信息
8.1 模型参数不是用户记忆
模型训练参数不会因为一次普通对话自动永久更新。Agent 的记忆通常由应用程序保存,在之后按需取回并放入上下文。
8.2 四类常见记忆
| 记忆类型 | 保存内容 | 典型存储 | 风险 |
|---|---|---|---|
| 工作记忆 | 当前任务步骤、临时结果 | 上下文、状态对象 | 上下文溢出 |
| 情节记忆 | 过去发生过什么 | 对话库、事件日志 | 错误历史被长期保留 |
| 语义记忆 | 稳定事实和偏好 | 数据库、向量库 | 信息过期或未经确认 |
| 程序记忆 | 如何执行任务 | 工作流、Skill、Prompt | 流程版本失控 |

记忆写入不应完全自动。系统需要判断信息是否值得保存、是否包含敏感数据、有效期多长以及用户能否查看和删除。
九、多 Agent 系统
多 Agent 系统把任务分给多个具有不同角色或工具的 Agent,例如研究 Agent 搜集资料、代码 Agent 实现功能、审核 Agent 检查结果。其优势是并行处理和职责隔离,缺点是通信成本、重复劳动和错误传播。
适合并行的任务应当能清楚拆分,例如同时查找不同来源;强依赖任务则更适合串行执行。多 Agent 不是越多越好。一个设计清晰的单 Agent 加确定性工具,常常比复杂的 Agent 群更稳定。
十、从用户请求到最终结果:完整示例
假设用户要求:“分析公司日志,找出疑似 Web 攻击并生成报告。”
-
系统 Prompt 规定只能读取指定日志,不能修改生产系统;
-
Agent 把目标拆分为日志发现、解析、规则筛选、语义复核和报告生成;
-
通过 MCP 文件资源读取日志结构;
-
调用日志解析工具提取请求字段;
-
通过 RAG 检索内部检测规则和历史案例;
-
LLM 对可疑请求进行上下文判断;
-
对证据不足的结果标注“不确定”,而不是直接判定成功攻击;
-
调用报告生成工具写入 Markdown;
-
验证报告记录数、引用和文件路径;
-
输出结果,并说明限制和需要人工复核的条目。
这个例子中,LLM 负责理解和不确定性判断,工具负责读取、解析和写文件,MCP 负责标准化连接,Prompt 负责规则,RAG 提供证据,验证器负责检查输出。任何一个组件都不能单独构成可靠 Agent。
十一、Agent 的主要风险与防护
| 风险 | 原因 | 主要防护 |
|---|---|---|
| 幻觉 | LLM 生成的是概率结果 | 外部检索、引用、规则验证、允许拒答 |
| Prompt 注入 | 不可信内容混入上下文 | 指令与数据隔离、最小权限、参数校验 |
| 越权执行 | 工具权限过大 | 权限分级、审批、沙箱、白名单 |
| 错误循环 | 缺少停止和错误处理 | 步数预算、超时、重试上限、状态机 |
| 数据泄露 | 敏感内容传给模型或工具 | 数据分类、脱敏、访问控制、审计 |
| 供应链风险 | 第三方 MCP 或插件不可信 | 来源验证、版本固定、代码审查、隔离 |
| 不可追责 | 只保留最终回答 | 保存工具调用、证据、审批和版本日志 |
最重要的设计原则是:模型可以建议行动,但最终权限必须由宿主系统控制。
十二、如何评价一个 Agent 是否可靠
不能只凭一次演示判断 Agent。评估应使用代表性任务集,并至少测量:
-
任务完成率;
-
最终答案准确率与证据支持率;
-
工具选择和参数正确率;
-
高风险操作拦截率;
-
平均步骤数、Token、时间和费用;
-
失败后恢复能力;
-
同一任务多次运行的一致性;
-
人工接管次数和原因。
评估还应覆盖异常情况,例如工具超时、空结果、权限不足、恶意网页、冲突指令和网络中断。真正可靠的 Agent 不只是成功时表现好,还要在失败时停止得安全、解释得清楚。
十三、容易混淆的概念
| 概念 | 它是什么 | 它不是什么 |
|---|---|---|
| LLM | 预测和生成 Token 的模型 | 实时数据库或完整 Agent |
| Prompt | 提交给模型的指令与上下文 | 可以保证百分之百正确的咒语 |
| Tool Calling | 模型提出结构化调用,宿主执行 | 模型直接控制外部系统 |
| MCP | AI 应用连接工具和数据的协议 | 模型、数据库或自主规划算法 |
| RAG | 生成前检索外部证据 | 自动保证资料真实 |
| Embedding | 表示语义关系的向量 | 可直接阅读的答案 |
| Memory | 应用保存并按需取回的信息 | 模型参数自动记住用户的一切 |
| Agent | 围绕目标运行的完整系统 | 只会聊天的 LLM |
十四、结论
理解 Agent 最有效的方法,是把它看成“概率模型与确定性软件的组合”。LLM 擅长理解语言、归纳信息和处理不确定问题;普通程序擅长权限控制、准确计算、状态保存和可重复执行。Prompt 告诉模型目标与边界,RAG 提供外部证据,Tool Calling 让模型提出动作,MCP 统一连接方式,记忆保存必要状态,控制循环持续推进任务,验证与审批防止错误扩大。
因此,一个优秀 Agent 的核心不是让模型拥有尽可能大的自由,而是让模型在清晰目标、充分证据、最小权限和可验证流程中发挥作用。
参考资料
-
Vaswani, A. et al. Attention Is All You Need, 2017.
-
Model Context Protocol. Architecture overview, accessed 2026-08-11.
-
Model Context Protocol. Specification 2025-06-18: Architecture.
-
Model Context Protocol. Transports.
-
OpenAI. Model guidance, accessed 2026-08-11.
图表使用说明
-
所有图均为独立 HTML 文件,打开后可直接截图。
-
画布采用固定宽度和分区式布局,正文设置了足够行距和内边距,避免文字重叠。
-
建议浏览器缩放保持 100%,全屏打开后截图。
-
图中为概念性流程,不表示某一家厂商产品的唯一实现。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐



所有评论(0)